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IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETR 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect of 
ETSI standards", which is available free of charge from the ETSI Secretariat. Latest updates are available on the ETSI 
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Foreword 



This Technical Specification (TS) has been produced by the Special Mobile Group (SMG) of the European 
Telecommunications Standards Institute (ETSI). 

This TS defines the interface between the Subscriber Identity Module (SIM) and the Mobile Equipment (ME) within the 
digital cellular telecommunications system. 

The contents of this TS are subject to continuing work within SMG and may change following formal SMG approval. 
Should SMG modify the contents of this TS it will then be republished by ETSI with an identifying change of release 
date and an increase in version number as follows: 

Version 6.x.y 

where: 

6 indicates GSM Phase 2+ Release 1997 

y the third digit is incremented when editorial only changes have been incorporated in the specification; 

X the second digit is incremented for all other types of changes, i.e. technical enhancements, corrections, 
updates, etc. 

The specification from which this TS has been derived was originally based on CEPT documentation, hence the 
presentation of this TS may not be entirely in accordance with the ETSI rules. 



Introduction 



The present document includes references to features which are not part of the original Phase 2+ release of the GSM 
Technical specifications. All subclauses which were changed as a result of these features contain a marker (see table 
below) relevant to the particular feature. GSM 10.01 will contain further information about these markers and GSM 
yearly releases. 

The following table lists all new features that were introduced to this document after version 5.4.0. Changes that were 
made as corrections to existing featurers are not listed in this table. It should be noted that following a decision made at 
ETSI SMG #25 requiring that all specifications containing a release 97 work item be released as a version 6.x.y. 
Consequently, new release 97 features approved at or after ETSI SMG #25 are found only in the version 6.x. y of the 
present document. 



GSM 11.14 version 6.0.0 GSM Release 1997 



TS 101 267 V6.0.0 (1998-04) 



Feature 


Release 


Marker 


Help information facility 


1997 


$(Helplnfo)$ 


Extended Results 


1997 


$(ExtdRes)$ 


Network Measurement Results included in PROVIDE LOCAL 
INFORMATION 


1997 


$(NMR)$ 


Default Choice for GET INPUT command 


1997 


${DefChoice)$ 


Items next action indication 


1997 


$(NextAction)$ 


Cell identity in Call Control by SIM 


1997 


${CellidCC)$ 


SEND USSD command 


1997 


$(SendUSSD)$ 


MO short message control by SIM 


1997 


${MOSMcontrol)$ 


Indication to be given to the user 


1997 


${lndication)$ 


Default selected item 


1997 


$(Defltem)$ 


Event driven information 


1997 


$(Event)$ 


Universal two byte coded Character Set 


1997 


$(UCS2)$ 
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1 Scope 



The present document defines the interface between the Subscriber Identity Module (SIM) and the Mobile Equipment 
(ME), and mandatory ME procedures, specifically for "SIM Application Toolkit". 

SIM Application Toolkit is a set of commands and procedures for use during the network operation phase of GSM, in 
addition to those defined in GSM 11.11 [14]. 

Specifying the interface is to ensure interoperability between a SIM and an ME independently of the respective 
manufacturers and operators. The concept of a split of the Mobile Station (MS) into these elements as well as the 
distinction between the GSM network operation phase, which is also called GSM operations, and the administrative 
management phase are described in GSM 02.17 [3]. 

The present document defines: 
the commands; 
the application protocol; 
the mandatory requirements on the SIM and ME for each procedure. 

Unless otherwise stated, references to GSM also apply to DCS 1800. 

This standard does not specify any aspects related to the administrative management phase. Any internal technical 
realization of either the SIM or the ME are only specified where these reflect over the interface. This standard does not 
specify any of the security algorithms which may be used. 

This Technical Specification defines an enhancement for GSM Phase 2+ of the SIM/ME interface for GSM Phase 2. 
While all attempts have been made to maintain phase compatibility, any issues that specifically relate to Phase 1 should 
be referenced from within the relevant Phase 1 specification. 



Normative references 



References may be made to: 

a) specific versions of publications (identified by date of publication, edition number, version number, etc.), in 
which case, subsequent revisions to the referenced document do not apply; or 

b) all versions up to and including the identified version (identified by "up to and including" before the version 
identity); or 

c) all versions subsequent to and including the identified version (identified by "onwards" following the version 
identity); or 

d) publications without mention of a specific version, in which case the latest version applies. 

A non-specific reference to an ETS shall also be taken to refer to later versions published as an EN with the same 
number. 

[1] GSM 01.02: "Digital cellular telecommunications system (Phase 2+); General description of a 

GSM Public Land Mobile Network (PLMN)". 

[2] GSM 01.04 (ETR 350): "Digital cellular telecommunications system (Phase 2+); Abbreviations 

and acronyms". 

[3] GSM 02.17 (ETS 300 922): "Digital cellular telecommunications system; Subscriber Identity 

Modules (SIM) Functional characteristics". 

[4] GSM 02.30 (ETS 300 907): "Digital cellular telecommunications system (Phase 2+); 

Man-Machine Interface (MMI) of the Mobile Station (MS)". 

[5] GSM 03.38 (ETS 300 900): "Digital cellular telecommunications system (Phase 2+); Alphabets 

and language-specific information". 
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[6] GSM 03.40 (ETS 300 901): "Digital cellular telecommunications system (Phase 2+); Technical 

realization of the Short Message Service (SMS) Point-to-Point (PP)". 

[7] GSM 03.41 (ETS 300 902): "Digital cellular telecommunications system (Phase 2+); Technical 

realization of Short Message Service Cell Broadcast (SMSCB)". 

[8] GSM 04.08 (ETS 300 940): "Digital cellular telecommunications system (Phase 2+); Mobile radio 

interface layer 3 specification". 

[9] GSM 04. 1 1 (ETS 300 942): "Digital cellular telecommunications system (Phase 2+); 

Point-to-Point (PP) Short Message Service (SMS) support on mobile radio interface". 

[10] GSM 04.80 (ETS 300 950): "Digital cellular telecommunications system (Phase 2+); Mobile radio 

interface layer 3 supplementary services specification; Formats and coding". 

[11] GSM 04.90 (ETS 300 957): "Digital cellular telecommunications system; Unstructured 

Supplementary Service Data (USSD) - Stage 3". 

[12] GSM 07.05: "Digital cellular telecommunications system (Phase 2+); Use of Data Terminal 

Equipment - Data Circuit terminating Equipment (DTE - DCE) interface for Short Message 
Service (SMS) and Cell Broadcast Service (CBS)". 

[13] GSM 09.91 (ETR 360): "Digital cellular telecommunications system; Interworking aspects of the 

Subscriber Identity Module - Mobile Equipment (SIM - ME) interface between Phase 1 and 
Phase 2". 

[14] GSM 11.11 (ETS 100 608): "Digital cellular telecommunications system (Phase 2); Specification 

of the Subscriber Identity Module - Mobile Equipment (SIM - ME) interface" 

[15] CCITT Recommendation E.164: "Numbering plan for the ISDN era". 

[16] ISO/IEC 7816-3 (1989): "Identification cards - Integrated circuit(s) cards with contacts, Part 3: 

Electronic signals and transmission protocols". 

[17] ISO/IEC 7816-6 (1995): "Identification cards - Integrated circuit(s) cards with contacts, Part 6 

Inter-industry data elements". 

[18] GSM 02.40 (ETS 300 512): "Digital cellular telecommunications system (Phase 2); Procedures for 

call progress indications". 

[19] GSM 02.07 (ETS 300 906): "Digital cellular telecommunications system (Phase 2+); Mobile 

Stations (MS) features". 

[20] GSM 1 1 . 1 1 (TS 100 977): "Digital cellular telecommunications system (Phase 2+); Specification 

of the Subscriber Identity Module - Mobile Equipment (SIM - ME) interface". 

[21] GSM 11.12 (ETS 300 641): "Digital cellular telecommunications system (Phase 2); Specification 

of the 3 Volt Subscriber Identity Module - Mobile Equipment (SIM - ME) interface". 

[22] GSM 03.22 (ETS 300 535): "Digital cellular telecommunications system (Phase 2); Functions 

related to Mobile Station (MS) in idle mode". 

[23] GSM 04.07 (ETS 300 556): "Digital cellular telecommunications system (Phase 2); Mobile radio 

interface signalling layer 3; General aspects". 
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3 Definitions, abbreviations and symbols 

3.1 Definitions 

For the purposes of the present document, the following definitions apply. For further information and definitions refer 

to GSM 01.02 [1]. 

application: An application consists of a set of security mechanisms, files, data and protocols (excluding transmission 
protocols). 

application protocol: The set of procedures required by the application. 

card session: A link between the card and the external world starting with the ATR and ending with a subsequent reset 
or a deactivation of the card. 

data object: Information seen at the interface for which are defined a tag (identifier), a length and a value. Data objects 
can be either BER-TLV (objects that conform to the Basic Encoding Rules of ASN. 1) or SIMPLE-TLV. In this 
specification, all BER-TLV data objects are "primitive": the value part consists only of SIMPLE-TLV data objects. 

padding: One or more bits appended to a message in order to cause the message to contain the required number of bits 
or bytes. 

proactive SIM: A SIM which is capable of issuing commands to the ME within the T=0 protocol. 

proactive SIM session: Sequence of related SIM application toolkit commands and responses. A proactive SIM session 
starts with the status response '91 xx' (proactive command pending) and ends with a status response of '90 00' (normal 
ending of command) after Terminal Response. 

SIM application session: The execution of a sequence of commands internal to the SIM that can result in the 
performance of one or several proactive SIM sessions. The SIM application session can be started by any event in the 
card session, and can execute for the duration of the card session. Processing of the SIM application session will not 
interfere with normal GSM operation. 

SIM Application Toolkit: A set of applications and related procedures which may be used during a GSM session. 

3.2 Abbreviations 

For the purpose of the present document, the following abbreviations apply, in addition to those listed in 
GSM 01.04 [2]: 

A3 Algorithm 3, authentication algorithm; used for authenticating the subscriber 

A5 Algorithm 5, cipher algorithm; used for enciphering/deciphering data 

A8 Algorithm 8, cipher key generator; used to generate K^, 

A3 8 A single algorithm performing the functions of A3 and A8 

ADN Abbreviated Dialling Number 

APDU Application Protocol Data Unit 

BCD Binary Coded Decimal 

BDN Barred Dialling Number 

BER Basic Encoding Rules of ASN. 1 

CB Cell Broadcast 

CBMI Cell Broadcast Message Identifier 

CCP Capability/Configuration Parameter 

DCS Digital Cellular System 

DTMF Dual Tone Multiple Frequency 

EF Elementary File 

ETSI European Telecommunications Standards Institute 

etu elementary time unit 

FDN Fixed Dialling Number 

GSM Global System for Mobile communications 

ID IDentifier 
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lEC International Electrotechnical Commission 

IMEI International Mobile Equipment Identity 

IMSI International Mobile Subscriber Identity 

ISO International Organization for Standardization 

Kc Cryptographic key; used by the cipher A5 

Ki Subscriber authentication key; the cryptographic key used by the authentication algorithm, A3, and 

cipher key generator, A8 

Igth The (specific) length of a data unit 

LND Last Number Dialled 

ME Mobile Equipment 

MMI Man Machine Interface 

MS Mobile Station 

NMR Network Measurement Results (see also GSM 04.08 [8]) 

NPI Numbering Plan Identifier 

RAND A RANDom challenge issued by the network 

RFU Reserved for Future Use 

SIM Subscriber Identity Module 

SMS Short Message Service 

SRES Signed RESponse calculated by a SIM 

SS Supplementary Service 

SSC Supplementary Service Control string 

SW1/SW2 Status Word 1 / Status Word 2 

TLV Tag, length, value. 

TON Type Of Number 

TP Transfer layer Protocol 

TS Technical Specification 

UCS2 Universal two byte coded Character Set 

USSD Unstructured Supplementary Service Data 



3.3 Symbols 



'0' to '9' and 'A' to 'F' The sixteen hexadecimal digits. 

$(CellidCC)$ This marker denotes that text in the relevant subclause contains references to a specific yearly 

release. See the introduction for further information. 
$ (Event) $ see above. 

$(ExtdRes)$ see above. 
$(DefItem)$ see above. 
$(DefChoice)$ see above. 
$(HelpInfo)$ see above. 
$(Indication)$ see above. 
$(MOSMcontrol)$ see above. 
$(NextAction)$ see above. 
$(NMR)$ see above. 

$(SendUSSD)$ see above. 
$(UCS2)$ see above 

4 Overview of SIM Application Toolkit 

The SIM Application Toolkit provides mechanisms which allow applications, existing in the SIM, to interact and 
operate with any ME which supports the specific mechanism(s) required by the application. 

The following mechanisms have been defined. These mechanisms are dependent upon the commands and protocols 
relevant to SIM AppHcation Toolkit in GSM 11.11 [20]. 



4.1 



Profile Download 



Profile downloading provides a mechanism for the ME to tell the SIM what it is capable of. The ME knows what the 
SIM is capable of through the SIM Service Table and EFpjj^gg. 
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4.2 Proactive SIM 

Proactive SIM gives a mechanism whereby the SIM can initiate actions to be taken by the ME. These actions include: 

- display text from the SIM to the ME; 
send a short message; 

set up a voice call to a number held by the SIM; 

set up a data call to a number and bearer capabilities held by the SIM; 

send a SS control or USSD string; 

- play tone in earpiece; 

initiate a dialogue with the user; 

SIM initialization request and notification of changes to EF(s); 

- provide local information from the ME to the SIM. 

If $(HelpInfo)$ is supported, then for each command involved in the dialog with the user, a help information may be 
available, either for each item of a list of items proposed to the user, or with each command requesting a response from 
the user. If a proactive command involved in the dialog with the user indicates the availability of the help feature, the 
support of this feature is optional for the ME. 

4.3 Data download to SIM 

Data downloading to the SIM uses the transport mechanisms of SMS point-to-point and Cell Broadcast. Transferral of 
information over the SIM-ME interface uses the ENVELOPE command. 

4.4 Menu selection 

A set of possible menu entries is supplied by the SIM in a proactive SIM command. The menu selection mechanism is 
used to transfer the SIM application menu item which has been selected by the user to the SIM. If $(HelpInfo)$ is 
supported, the menu selection mechanism may also be used for requesting help information on the items of the SIM 
application menu. 



4.5 Call control by SIM 



When this service is activated by the SIM, all dialled digit strings, supplementary service control strings and USSD 
strings are first passed to the SIM before the ME sets up the call, the supplementary service operation or the USSD 
operation. If $(CellidCC)$ is supported, the ME shall also pass to the SIM at the same time its current serving cell. The 
SIM has the ability to allow, bar or modify the call, the supplementary service operation or the USSD operation. The 
SIM also has the ability to replace a call request, a supplementary service operation or a USSD operation by another call 
request or supplementary service operation or USSD operation. For example, a call request can be replaced by a 
supplementary service operation or a USSD operation, and vice-versa. 

4.6 MO Short Message control by SIM 

This subclause applies only if $(MOSMcontrol)$ is supported. 

When this service is activated by the SIM, all MO short messages are first passed to the SIM before the ME sends the 
short message. The ME shall also pass to the SIM at the same time its current serving cell. The SIM shall have the 
ability to allow the sending, bar the sending or modify the destination address of the short message before sending it. 

4.7 Event download 

This subclause applies only if $(Event)$ is supported. 

A set of events to monitor for is supplied by the SIM in a proactive SIM command. The event download mechanism is 
used to transfer details of the event to the SIM, when it occurs. Events that the ME can report to the SIM include 
incoming calls, location status, and availability of the screen for applications. This service is supported if $(Event)$ is 
supported. 
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4.8 Security 



Applications designed using the features in this specification may require methods to ensure data confidentiaHty, data 
integrity, and data sender validation, or any subset of these. Requirements for these mechanisms are defined in clause 
15. 



Profile download 



5.1 



Procedure 



The profile download instruction is sent by the ME to the SIM as part of the SIM initialization procedure. This 
procedure is specified in GSM 11.11 [14]. In this procedure, the ME reads EFpjj^gg. If EFpj^^^g indicates that the SIM 
requires the ME to perform the profile download procedure, then the ME shall, after having performed the CHVl 
verification procedure and before selecting EFimsi or EFloci, send the TERMINAL PROFILE command, as specified 
below, to the SIM. The profile sent by the ME shall state the facilities relevant to SIM Application Toolkit that are 
supported by the ME. 

This procedure is important, as it is by this that the SIM knows what the ME is capable of, and the SIM can then limit its 
instruction range accordingly. If no command is sent by the ME, the SIM shall assume that the ME does not support 
SIM Application Toolkit. 

5.2 Structure and coding of TERMINAL PROFILE 

Direction: ME to SIM 

The command header is specified in GSM 11.11 [14]. 

Command parameters/data: 



Description 


Section 


M/0 


Length 


Profile 


- 


M 


igth 



Profile: 

Contents: The list of SIM Application Toolkit facilities that are supported by the ME. 

Coding: 

1 bit is used to code each facility: 

bit = 1: facility supported by ME 

bit = 0: facility not supported by ME 

First byte (Download) : 



Profile download 

SMS-PP data download 

Cell Broadcast data download 

Menu selection 

RFU, bit = 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


bl 
















1 
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Second byte (Other) 



b8 b7 b6 b5 b4 b3 b2 bl 



Command result 

Call Control by SIM 

Cell identity included in Call Control 

by SIM, if $(CellidCC)$ is supported 
MO short message control 

by SIM if $ (MOSMcontrol) $ is supported 
Handling of the alpha identifier according 

to $( Indication) $ 
UCS2 Entry supported ($(UCS2)$ only) 
UCS2 Display supported ($(UCS2)$ only) 
RFU, bit = 



Third byte (Proactive SIM) 



b8 b7 b6 b5 b4 b3 b2 bl 



Proactive SIM: DISPLAY TEXT 
Proactive SIM: GET INKEY 
Proactive SIM: GET INPUT 
Proactive SIM: MORE TIME 
Proactive SIM: PLAY TONE 
Proactive SIM: POLL INTERVAL 
Proactive SIM: POLLING OFF 
Proactive SIM: REFRESH 



Fourth byte (Proactive SIM) 



b8 b7 b6 b5 b4 b3 b2 bl 



Proactive 
Proactive 
Proactive 

Proactive 



Proactive 
Proactive 

Proactive 

Proactive 



SIM: SELECT ITEM 

SIM: SEND SHORT MESSAGE 

SIM: SEND SS 

SIM: SEND USSD if 

$(SendUSSD)$ is supported 

RFU otherwise 
SIM: SET UP CALL 
SIM: SET UP MENU 
SIM: PROVIDE LOCAL INFORMATION 

(MCC,MNC, LAC, Cell ID&IMEI) 
SIM: PROVIDE LOCAL INFORMATION 

(NMR (if $ (NMR) $ is 
supported) 



Fifth byte (Event driven information) : (if $ (Event) $ is supported) 



bf 



b7 



b6 



b5 



b4 



b3 



b2 



bl 



Proactive SIM: SET UP EVENT LIST 

Event: MT call 

Event: Call connected 

Event: Call disconnected 

Event: Location status 

Event: User activity 

Event: Idle screen available 

RFU, bit = 

If $ (Event) $ is not supported, this byte 

is RFU, all bits = 0. 



Sixth byte (Event driven information): (if $ (Event) $ is supported) 



bf 



b7 



b6 



b5 



b4 



b3 



b2 



bl 



RFU, bit = 



Subsequent bytes: 



bf 



b7 



b6 



b5 



b4 



b3 



b2 



bl 



RFU, bit = 



RFU bits, and all bits of subsequent bytes, are reserved to indicate future facilities. A SIM supporting only the 
features of SIM Application Toolkit defined here shall not check the value of RFU bits. 
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Response parameters/data: None. 



6 Proactive SIM 

6.1 Introduction 

GSM 11.11 [14] defines that the ME communicates to the SIM using the T=0 protocol, which is specified in 
ISO/IEC 7816-3 [16]. The ME is always the "master" and initiates commands to the SIM, and therefore there is no 
mechanism for the SIM to initiate a communication with the ME. This limits the possibility of introducing new SIM 
features requiring the support of the ME, as the ME needs to know in advance what actions it should take. 

The proactive SIM service provides a mechanism which stays within the protocol of T=0, but adds a new status response 
word SWl. This status response has the same meaning as the normal ending ('90 00'), and can be used with most of the 
commands that allow the normal ending, but it also allows the SIM to say to the ME "I have some information to send to 
you". The ME then uses the FETCH function to find out what this information is. 

To avoid cross-phase compatibility problems, these functions shall only be used between a proactive SIM and an ME 
that supports the proactive SIM feature. 

The SIM can issue a variety of commands through this mechanism, given in alphabetical order: 

DISPLAY TEXT, which displays text on screen (no more than 160 characters). A high priority is available, to 
replace anything else on screen. 

GET INKEY, which sends text to the display and requests a single character response in return. It is intended to 
allow a dialogue between the SIM and the user, particularly for selecting an option from a menu. 

GET INPUT, which sends text to the display and requests a response in return. It is intended to allow a dialogue 
between the SIM and the user. 

MORE TIME, which does not request any action from the ME. The ME is required to respond with 
TERMINAL RESPONSE (OK) as normal - see below. The purpose of the MORE TIME command is to provide 
a mechanism for the SIM Application Toolkit task in the SIM to request more processing time. 

PLAY TONE, which requests the ME to play a tone in its earpiece, ringer, or other appropriate loudspeaker. 

- POLL INTERVAL, which negotiates how often the ME sends STATUS commands to the SIM during idle 
mode. Polling is disabled with POLLING OFF. Use of STATUS for the proactive SIM is described in 

GSM 11.11 [14]. 

- PROVIDE LOCAL INFORMATION which requests the ME to pass local information to the SIM, for 
example the mobile country and network codes (MCC + MNC) of the network on which the user is registered. 

REFRESH, which requests the ME to carry out a SIM initialization according to GSM 11.11 subclause 12.2.1, 
and/or advises the ME that the contents or structure of EFs on the SIM have been changed. The command also 
makes it possible to restart a card session by resetting the SIM. 

SELECT ITEM, where the SIM supplies a list of items, and the user is expected to choose one. The ME 
presents the list in an implementation-dependent way. 

- SEND SHORT MESSAGE, which sends a short message or SMS-COMMAND to the network. 
SEND SS, which sends a SS request to the network. 

- SEND USSD, which, if $(SendUSSD)$ is supported, sends a USSD string to the network. 

SET UP CALL, of which there are three types: 

set up a call, but only if not currently busy on another call; 
set up a call, putting all other calls (if any) on hold; 
set up a call, disconnecting all other calls (if any); 



GSM 1 1 .1 4 version 6.0.0 GSM Release 1 997 17 TS 1 01 267 V6.0.0 (1 998-04) 



SET UP EVENT LIST (if $(Event)$ is supported), where the SIM supplies a Hst of events which it wants the 
ME to provide details of when these events happen. 

SET UP MENU, where the SIM supplies a list of items to be incorporated into the ME's menu structure. 

The ME tells the SIM if the command was successful or not using the command result procedure defined in subclause 
6.7. Responsibility for what happens after that (whether to repeat the command, try another one immediately, try again 
sometime later, or not to try again at all) lies with the SIM application. However, the SIM application needs to know 
why the command failed, so the ME provides the SIM with the result of the command. 

Results are grouped into three main types: 

- OK. 

Temporary problem. These results are further broken down into types of temporary problems, and specific 
causes. Generally, they indicate to the SIM that it may be worth trying again. 

Permanent problem. These results are again further broken down into types of permanent problems, and specific 
causes. Generally, they indicate to the SIM that it is not worth trying again during this GSM session. 

6.2 Identification of proactive SIIVIs and of IVIE support 

A proactive SIM shall be identified by having the proactive SIM service activated in the SIM Service Table (see 
GSM 11.11 [14]). An ME that supports proactive SIMs shall be identified as such when it sends a TERMINAL 
PROFILE command during SIM initialization. The ME shall then send STATUS commands to the SIM at intervals 
determined by the poll interval procedure (see subclause 6.4.6). 

A proactive SIM shall not send any command requests (status bytes SWl SW2 = '91 XX') to a mobile that does not 
support the proactive SIM feature. 

An ME that supports the proactive SIM feature shall not send proactive SIM related commands to a SIM that does not 
have the proactive SIM service activated. 



6.3 General procedure 



For all of the procedures that can end in '90 00' (indicating normal ending to the command), and which cannot end in '9F 
XX' (response data available from SIM), a proactive SIM operating with an ME that supports proactive SIMs may 
instead use the status response '91 XX'. 

The response code '91 XX' shall indicate to the ME that the previous command has been successfully executed by the 
SIM in the same way as '90 00' (i.e. "OK"), but additionally it shall indicate response data which contains a command 
from the SIM for a particular ME procedure (defined in subclause 6.4). 

The value 'XX' indicates the length of the response data. The ME shall use the FETCH command to obtain this data. 

GSM 11.11 [20] shows how the SIM can initiate a proactive command in each of the five cases of transmission protocol 
identified in GSM 11.11 [14]. Some commands require the SIM to indicate that it has response data for the ME (through 
SWI/SW2 = '9F XX'), and the ME gets this data using the GET RESPONSE command. 

When the ME has received a command from the SIM, it shall attempt to process the command immediately. 

If the command has been successfully executed, the ME shall inform the SIM as soon as possible, using 
TERMINAL RESPONSE. 

If the command was not successfully executed, the ME shall inform the SIM as soon as possible using 
TERMINAL RESPONSE with an error condition. 

Responsibility for re-trying lies with the SIM application. The SIM application can make a judgement whether to send 
the same command again, to send a different one, or not to try again, from the information given by the ME in 
TERMINAL RESPONSE. If the SIM application wishes the ME to try again, it shall issue a new (identical) command. 

Only one proactive command can be ongoing at any one time. 
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6.4 Proactive SIM commands and procedures 

6.4.1 DISPLAY TEXT 

This command instructs the ME to display a text message. It allows the SIM to define the priority of that message, and 
the text string format. 

Two types of priority are defined: 

Display normal priority text on screen. 
Display high priority text on screen. 

The text string can be in one of three formats: 

- packed format in SMS default alphabet - (see 12.15.2); 
unpacked format in SMS default alphabet - (see 12.15.2); 

- UCS2 alphabet format if $(UCS2)$ is supported - (see 12. 15.3). 

A flag (see command qualifier, subclause 12.6) shall be set to inform the ME whether the availability of the screen for 
subsequent information display after its use for 'Display Text' should be either after a short delay (the duration of the 
delay being at the discretion of the ME manufacturer), or following a user MMI action. 

If the user has indicated the need to end the proactive SIM application session, the ME shall send a TERMINAL 
RESPONSE with "Proactive SIM application session terminated by the user" result value. 

If the user has indicated the need to go backwards in the proactive SIM application session, the ME shall send a 
TERMINAL RESPONSE with "Backward move in the proactive SIM session requested by the user" result 
value. 

If $(ExtdRes)$ is supported and if a flag of the command qualifier (see subclause 12.6) indicates that the ME 
shall wait for the user to clear message and if the ME decides that no user response has been received, the ME 
shall send a TERMINAL RESPONSE with "No response from user" result value. 

Otherwise, the ME shall send TERMINAL RESPONSE (Command performed successfully) at the expiration of 
the short delay, or following a user MMI action not described above. 

In each case the availability of the screen for the subsequent information display is defined in clause 6.9. 

NOTE: For the case where the text is cleared after a short delay, the ME may also allow the user to clear the 
display via the MMI prior to this. 

The ME shall reject normal priority text commands if the screen is currently being used for more than its normal stand- 
by display. If the command is rejected, the ME informs the SIM using TERMINAL RESPONSE (ME currently unable 
to process command - screen busy). 

High priority text shall be displayed on the screen immediately, except if there is a conflict of priority level of alerting 
such as incoming calls or a low battery warning. In that situation, the resolution is left to the ME. If the command is 
rejected in spite of the high priority, the ME shall inform the SIM using TERMINAL RESPONSE (ME currently unable 
to process command - screen is busy). 

If $(HelpInfo)$ is supported and help information is requested by the user, this command may be used to display help 
information on the screen. The help information should be sent as high priority text and with the option that it should be 
cleared after a short delay. 

6.4.2 GET INKEY 

This command instructs the ME to display text, and to expect the user to enter a single character. Any response entered 
by the user shall be passed transparently by the ME to the SIM. 

The text can be in one of three formats: 

- packed format in SMS default alphabet - (see 12.15.2); 

- unpacked format in SMS default alphabet - (see 12.15.2); 
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UCS2 alphabet format if $(UCS2)$ is supported - (see 12.15.3). 
The response can be from one of three character sets. This is specified by the SIM: 

- digits only (0-9, *, #, and +); 
characters from the SMS default alphabet; 

characters from the UCS2 alphabet if $(UCS2)$ is supported. 

Upon receiving the command, the ME shall display the text. The ME shall allow the user to enter a single character in 
response. 

If the user has indicated the need to go backwards in the proactive SIM session, the ME shall send a TERMINAL 
RESPONSE with "Backward move in the proactive SIM session requested by the user" result value. 

If the user has indicated the need to end the proactive SIM session, the ME shall send a TERMINAL 
RESPONSE with "Proactive SIM session terminated by the user" result value. 

If the ME decides that no user response has been received, the ME shall send a TERMINAL RESPONSE with 
"No response from user" result value. 

If the SIM requests a digit only, the ME shall only allow the user to enter a character from the digits 0-9, *, # and 
+. When the user has entered a digit, the ME shall pass the entered digit transparently to the SIM, using 
TERMINAL RESPONSE. 

If the $(HelpInfo)$ feature is supported and help information is available for the command and if the user has 
indicated the need to get help information, the ME shall send a TERMINAL RESPONSE with "help information 
required by the user" result value. 

If the SIM requests a character from the SMS default alphabet, the ME shall allow the user to enter a character 
using characters from this alphabet. When the user has entered a character, the ME shall pass the entered 
character transparently to the SIM, using TERMINAL RESPONSE. 

NOTE: If the MMI of the ME requires more than one keypress in order to select a character, it is an 

implementation decision for the ME manufacturer how to indicate completion (e.g. timeout, pressing 
SEND, OK). It may be useful to echo the input character on the display. 

For digits only (0-9, *,# and +) and SMS default alphabet characters sets, the response shall be coded using the SMS 
default alphabet in unpacked format. 

6.4.3 GET INPUT 

This command instructs the ME to display text, and that any response string entered by the user shall be passed 
transparently by the ME to the SIM. If $(DefChoice)$ is supported, and if the SIM provides a default text, the ME shall 
display this default text, which the user may accept, reject or edit as the response string. 

The text can be in one of three formats: 

- packed format in SMS default alphabet (see 12.15.2); 
unpacked format in SMS default alphabet (see 12.15.2); 

- UCS2 alphabet format if $(UCS2)$ is supported (see 12. 15.3). 

The SIM indicates how many characters are expected for the response string, by giving a minimum and a maximum 
acceptable length. 

The SIM specifies three variables for the response string it is expecting from the user: 

the response contains either digits only (0-9, *, # and +) or characters from the SMS default alphabet; 

the response for digits only (0-9, *,# and +) or characters from SMS default alphabet is either in an unpacked 

format or in a packed format; 

the ME may display the text string being entered by the user (the response), or the ME shall hide (i.e. not 

display) the actual text string. 
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The combination of characters from the SMS default alphabet and hidden entry mode is not allowed. In hidden entry 
mode, only digits from the set "0-9","*" and "#" are allowed for the user input. "+" is not allowed for user input in this 
mode. 

If the SIM requests that the user input (text string) is to be hidden, it is permissible for the ME to indicate the entry of 
characters, so long as the characters themselves are not revealed. 

Upon receiving the command, the ME shall display the text. The ME shall allow the user to enter characters in response. 

The ME MMI is responsible for managing the entry of the correct number of characters. 

If the user has indicated the need to go backwards in the proactive SIM session, the ME shall send a TERMINAL 
RESPONSE with "Backward move in the proactive SIM session requested by the user" result value. 

If the user has indicated the need to end the proactive SIM session, the ME shall send a TERMINAL 
RESPONSE with "Proactive SIM session terminated by the user" result value. 

If the ME decides that no user response has been received, the ME shall send a TERMINAL RESPONSE with 
"No response from user" result value. 

- If the SIM requests digits only, the ME shall only allow the user to enter the digits 0-9, *, # and +. When the user 
presses SEND (or otherwise indicates completion), the ME shall pass the entered digit string transparently to the 
SIM, using TERMINAL RESPONSE. 

If the SIM requests characters from the UCS2 alphabet or SMS default alphabet, the ME shall allow the user to 
enter a character string using characters from one of these alphabets. When the user presses SEND (or otherwise 
indicates completion), the ME shall pass the entered text string transparently to the SIM, using TERMINAL 
RESPONSE. 

If $(HelpInfo)$ is supported and help information is available for the command and if the user has indicated the 
need to get help information, the ME shall send a TERMINAL RESPONSE with 'help information required by 
the user' result value. 

If the SIM requests the user input to be in packed format, then the ME shall pack the text according to GSM 03.38 [5] 
before submitting it to the SIM. 

6.4.4 MORE TIME 

This procedure is provided to allow the SIM Application Toolkit task in the SIM more time for processing, where the 
processing is so long that it is in danger of affecting normal GSM operation, and clock stop prevents processing to take 
place in the background. 

The ME shall take no extraordinary action when it receives this command, and all other operations shall be unaffected. 
The ME shall conclude the command by sending TERMINAL RESPONSE (OK) to the SIM, as soon as possible after 
receiving the MORE TIME command. 

6.4.5 PLAY TONE 

This command instructs the ME to play an audio tone. 

Upon receiving this command, the ME shall check if it is currently in, or in the process of setting up (SET-UP message 
sent to the network, see GSM 04.08 [8]), a speech call. 

If the ME is in, or is setting up a speech call, it shall superimpose the tone on top of the downlink audio (if any), 
for the duration given in the command. The progress or current state of the call shall not be affected in any way. 

If the ME is not in or setting up a speech call, it shall route the audio to the external ringer, or other appropriate 
audio device, and play the tone for the duration given in the command. 

If the user has indicated the need to end the proactive SIM application session while the ME plays the tone, the 
ME shall stop playing the tone and shall send a TERMINAL RESPONSE with "Proactive SIM application 
session terminated by the user" result value. 
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If ME support for the specific tone requested is optional, and the ME does not support this particular tone, the 
ME shall inform the SIM using TERMINAL RESPONSE (Command beyond ME's capabilities). 

This proactive command contains no information on how a call is progressing; therefore the ME shall not generate any 
verbal indication or display any text or graphical indication about the normal meaning of this tone (e.g. display "called 
subscriber busy"). If the SIM wishes to convey a meaning in text to the user, it shall do this through the alpha identifier 
data object. 

If the ME is required to generate a supervisory tone due to the progress of the current call (e.g. the network sends the 
ME call control cause information) as defined in GSM 02.40 [18], then the call supervisory tone shall take precedence 
over the tone requested by the SIM. 

6.4.6 POLL INTERVAL 

This procedure negotiates how often the ME shall send STATUS commands related to Proactive Polling (defined in 
GSM 11.11 [20]). The SIM indicates the poll interval it requests from then onwards, and the ME responds through 
TERMINAL RESPONSE with the maximum interval that it will use. If the ME does not support the poll interval 
requested by the SIM, then the ME shall respond with the closest interval to the one requested by the SIM, or, if the 
intervals the ME can offer are equidistant (higher and lower) from the SIM's request, the ME shall respond with the 
lower interval of the two. 

NOTE: Applications on the SIM should not request short time intervals for an extended period, as this will have 
an adverse effect on battery life. 

6.4.7 REFRESH 

The purpose of this command is to enable the ME to be notified of the changes to the SIM configuration that have 
occurred as the result of a SIM application activity. It is up to the SIM application to ensure that this is done correctly. 

The command supports five different modes: 

SIM Initialization. This mode tells the ME to carry out SIM initialization as it is defined in GSM 11.11 subclause 
12.2.1 only, starting after the CHVl verification procedure. The ME shall not reset the SIM electrically. 

- File Change Notification. This mode advises the ME of the identity of the EFs that have been changed (in 
structure and/or contents) in the SIM. This information can be used by the ME if there is an image of SIM EFs 
(e.g. the ADN file) in the ME's memory, to determine whether it needs to update this image. 

SIM Initialization and File Change Notification. This is a combination of the first two modes above. 

SIM Initialization and Full File Change Notification. This mode causes the ME to perform the SIM initialization 
procedure of the first mode above and advises the ME that several EFs have been changed (in structure or 
contents) in the SIM. If there is an image of SIM EFs in the ME's memory, the ME shall completely update this 
image. 

SIM Reset. This mode causes the ME to run the GSM session termination procedure and to deactivate the SIM in 
accordance with GSM 11.11 [20]. Subsequently, the ME activates the SIM again and starts a new card session. In 
case of a 3 Volt technology ME, the ME shall restart the SIM with the same supply voltage as in the previous 
session, if the ME can ensure that the SIM has not been changed in between. Otherwise, the ME shall perform the 
supply voltage switching in accordance with GSM 11.12 [21]. The ME shall not send the TERMINAL 
RESPONSE; this is an exception from the normal procedure, where TERMINAL RESPONSE is sent after 
completion of the command. The SIM Application shall interpret a new activation of the contacts of the SIM as 
an implicit TERMINAL RESPONSE. The SIM Reset mode is used when a SIM application requires ATR or 
complete SIM initialization procedures to be performed. SIM Applications should take into account that early 
implementations of SIM Application Toolkit in some MEs may send a TERMINAL RESPONSE after 
performing the REFRESH command involving resetting the SIM electrically. 

If the ME performs the REFRESH command successfully for only those EFs indicated in the mode, the ME shall inform 
the SIM using TERMINAL RESPONSE (OK), after it has completed its refreshing. 

For REFRESH commands with mode other than "SIM Reset", it is permissible for the ME, as part of its execution of the 
REFRESH command, to read EFs in addition to those notified by the SIM, or to perform a SIM initialisation, provided 
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that the procedure executed wholly encompasses the mode requested by the SIM. The ME shall not electrically reset the 
SIM. If the ME does the refreshing successfully, it shall inform the SIM using TERMINAL RESPONSE (Refresh 
performed with additional EFs read), after the ME has completed its refreshing. It should be noted that reading 
additional EFs will lengthen the refresh procedure. 

If the ME receives a REFRESH command while in a state where execution of the command would be unacceptable, 
upsetting the current user operation (e.g. notification during a call that the IMSI has changed), the ME shall inform the 
SIM using TERMINAL RESPONSE (ME currently unable to process command - currently busy on call) or 
TERMINAL RESPONSE (ME currently unable to process command - screen is busy) as appropriate. 

NOTE 1 : Many MEs copy an image of the SIM's memory to the ME at initialization to speed up access to these 

fields during a GSM session. One of the purposes of this coding of the REFRESH command is to enable 
MEs to change such an image efficiently. 

If, on receipt of the REFRESH command, the ME replies that it is busy (e.g. in call or navigating menus), the toolkit 
application may shorten the polling interval utilising the POLL INTERVAL command in order to resend the REFRESH 
command more frequently. 

It is recommended for the ME to minimise the use of sending temporary problem TERMINAL RESPONSE, as during 
the period between the SIM issuing a REFRESH command and the ME performing the refresh procedure, there may be 
inconsistencies between data held in the ME and in the SIM. However, responsibility for retrying of all pro-active 
commands lies with the SIM Application. 

6.4.8 SET UP MENU 

The SIM shall supply a set of menu items, which shall be integrated with the menu system (or other MMI facility) in 
order to give the user the opportunity to choose one of these menu items at his own discretion. Each item comprises a 
short identifier (used to indicate the selection) and a text string. The SIM shall include an alpha identifier which acts as a 
title for the list of menu items. If $(NextAction)$ is supported, the SIM may include an items next action indicator data 
object located at the end of the list of items. The inclusion of the items next action indicator is to allow the ME to 
indicate to the user the consequences of performing the selection of an item. 

NOTE: The maximum amount of data sent in one proactive SIM command is 256 bytes. It is therefore 

unavoidable that there is trade-off between the number of items and the length of the descriptive text (the 
alpha identifier of the SET-UP MENU command and the text strings of the items), e.g. for an average 
length of 10 bytes per text string the maximum amount of items is 18. 

The list of menu items shall then be part of the menu system of the ME and the user is allowed to select an item from 
this list. The presentation style is left as an implementation decision to the ME manufacturer. The menu provided by the 
SIM in the last SET UP MENU command shall no longer be part of the menu system of the ME if the ME is powered 
off or the SIM is removed or electrically reset. 

Any subsequent SET-UP MENU command replaces the current list of menu items supplied in the previous SET-UP 
MENU command. The SET-UP MENU command can also be used to remove a menu from the menu system in the ME; 
see sub-clause 6.6.7. 

When the ME has successfully integrated or removed the list of menu items, it shall send TERMINAL RESPONSE 
(OK) to the SIM. 

When the ME is not able to successfully integrate or remove the list of menu items, it shall sent TERMINAL 
RESPONSE (Command beyond ME's capabilities). 

When the user has selected one of the menu items of this menu item list, then the ME shall use the Menu Selection 
mechanism to transfer the identifier of the selected menu item to the SIM. 

If $(HelpInfo)$ is supported and help is available for the command and if the user has indicated the need to get help 
information on one of the menu items, the ME shall use the Menu Selection mechanism to inform the SIM about this 
help request. 
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6.4.9 SELECT ITEM 

The SIM shall supply a set of items from which the user may choose one. Each item comprises a short identifier (used to 
indicate the selection) and a text string. Optionally the SIM may include an alpha identifier. The alpha identifier is 
intended to act as a title for the list of items. If $(NextAction)$ is supported, the SIM may include an items next action 
indicator data object located at the end of the list of items. The inclusion of the items next action indicator is to allow the 
ME to indicate to the user the consequences of performing the selection of an item. 

If $ (Indication) $ is supported, the alpha identifier included by the SIM shall be used by the ME as the title for the list of 
items. 

NOTE: The maximum amount of data sent in one proactive SIM command is 256 bytes. It is therefore 

unavoidable that there is trade-off between the number of items and the length of the descriptive text (the 
alpha identifier of the SELECT ITEM command and the text strings of the items), e.g. for an average 
length of 10 bytes per text string the maximum amount of items is 18. 

The ME shall present the list of text strings to the user, and allow the user to select an item from this list. The 
presentation style is left as an implementation decision to the ME manufacturer. The menu provided by the SIM in the 
last SET UP MENU command shall no longer be part of the menu system of the ME if the ME is powered off or the 
SIM is removed or electrically reset. 

If $(Defltem)$ is supported, the SIM may supply with the list, if applicable, indication of the default item, e.g. the 
previously selected item. 

When the user has selected an item, the ME shall send TERMINAL RESPONSE (OK) to the SIM with the identifier of 
the item chosen. 

If the user has indicated the need to end the proactive SIM session, the ME shall send a TERMINAL 
RESPONSE with "Proactive SIM session terminated by the user" result value. 

If the user has indicated the need to go backwards in the proactive SIM session, the ME shall send a TERMINAL 
RESPONSE with "Backward move in the proactive SIM session requested by the user" result value. 

If the ME decides that no user response has been received, the ME shall send a TERMINAL RESPONSE with 
"No response from user" result value. 

If $(HelpInfo)$ is supported and help information is available for the command and if the user has indicated the 
need to get help information, the ME shall send a TERMINAL RESPONSE with 'help information required by 
the user' result value. 

6.4.1 SEND SHORT MESSAGE 

Two types are defined: 

- A short message to be sent to the network in an SMS-SUBMIT message, or an SMS-COMMAND message, 
where the user data can be passed transparently; 

A short message to be sent to the network in an SMS-SUBMIT message where the text needs to be packed by the 
ME. 

Where the text has been packed, the text string provided by the SIM shall not be longer than 160 characters. It shall use 
the SMS default 7-bit coded alphabet, packed into 8-bit octets, in accordance with GSM 03.38 [5]. The data coding 
indication contained in the Data Coding Scheme byte shall be "default alphabet". The text length (which is part of the 
SMS TPDU) given by the SIM shall state the number of 7-bit characters in the text string. The command details shall 
indicate "packing not required". 

8-bit data Short Messages may be sent by the SIM. The command shall indicate packing not required. The data coding 
indication contained in the Data Coding Scheme byte shall be "8 bit". The string shall not be longer than 140 bytes, and 
the length (in SMS TPDU) shall state the number of bytes in the string. 

If $(UCS2)$ is supported by the ME, 16-bit data Short Messages may be sent by the SIM. The text string provided by 
the SIM shall not be longer than 70 characters. It shall use the 16-bit UCS2 alphabet format, in accordance with GSM 
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03.38 [5]. The text length (which is part of the SMS TPDU) given by the SIM shall state the number of 16-bit characters 
in the text string. The command details shall indicate "packing not required". 

SMS commands may be sent by the SIM. These shall count as packed text message. The SMS TPDU from the SIM shall 
indicate SMS-COMMAND. The command details shall indicate "packing not required". 

Where packing by the ME is required, the text string provided by the SIM shall not be longer than 160 characters. It 
shall use the SMS default 7-bit coded alphabet as defined in GSM 03.38 [5] with bit 8 set to 0. The text length given by 
the SIM shall state the number of characters in the text string. The ME shall pack the text string and modify the Data 
Coding Scheme byte to "default alphabet" in accordance with GSM 03.38 [5] before submitting the message to the 
network. 

$(begin$(Indication)$)$ 

Optionally, the SIM may include in this command an alpha identifier. The use of this alpha identifier by the ME is 

described below : 

If the alpha identifier is provided by the SIM and is not a null data object, the ME shall use it to inform the user. 

This is also an indication that the ME should not give any other information to the user on the fact that the ME is 

sending a short message. 

If the alpha identifier is provided by the SIM and is a null data object (i.e. length = '00' and no value part), this is 

an indication that the ME should not give any information to the user on the fact that the ME is sending a short 

message. 

If the alpha identifier is not provided by the SIM, the ME may give information to the user concerning what is 

happening. 

$(end$(Indication)$)$ 

If the ME is capable of SMS-MO, then it shall send the data as a Short Message TPDU to the destination address. The 
ME shall give the result to the SIM using TERMINAL RESPONSE (indicating successful or unsuccessful transmission 
of the Short Message) after receiving an SMS RP-ACK or RP-Error from the network. If $(Indication)$ is supported, if 
an alpha identifier was provided by the SIM, the ME should not give any information to the user at the reception of SMS 
RP-ACK or RP-Error. 

6.4.11 SENDSS 

Even if the Fixed Dialling Number service is enabled, the supplementary service control string included in the SEND SS 
proactive command shall not be checked against those of the FDN list. 

Upon receiving this command, the ME shall decide if it is able to execute the command. Examples are given below, but 
the list is not exhaustive: 

If the command is rejected because the ME is busy on an SS transaction, the ME informs the SIM using 
TERMINAL RESPONSE (ME unable to process command - currently busy on SS transaction); 

If ($sendUSSD$) is supported and if the command is rejected because the ME is busy on a USSD transaction, the 
ME shall inform the SIM using TERMINAL RESPONSE (ME unable to process command - currently busy on 
USSD transaction); 

If the command is rejected because the ME does not support that Supplementary Service, the ME informs the 
SIM using TERMINAL RESPONSE (Command beyond ME's capabilities). 

If the ME is able to send the SS request, the ME shall: 

Send the SS request immediately, without need to alert the user first. 

$(release96)$: Optionally, the ME can give some audible or display indication concerning what is happening. 

$(begin$(Indication)$)$ 

Optionally, the SIM may include in this command an alpha-identifier. The use of this alpha-identifier by the ME 

is described below: 

If the alpha identifier is provided by the SIM and is not a null data object, the ME shall use it to inform the 
user. This is also an indication that the ME should not give any other information to the user on the fact that 
the ME is sending a SS request. 
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If the alpha identifier is provided by the SIM and is a null data object (i.e. length = '00' and no value part), 

this is an indication that the ME should not give any information to the user on the fact that the ME is sending 

an SS request. 

If the alpha identifier is not provided by the SIM, the ME may give information to the user concerning what is 

happening. 

$(end$(Indication)$)$ 

Once a SS Return Result message not containing an error has been received from the network, the ME shall 

inform the SIM that the command has been successfully executed, using TERMINAL RESPONSE. This 

command shall include the contents of SS Return Result as additional data. 

$(release96)$: Optionally, the ME may display the result on screen. 

$(Indication)$: If a null alpha identifier was provided by the SIM, the ME should not give any information to the 

user at the reception of an SS Return Result message; 

If the command is rejected because the network cannot support or is not allowing the Supplementary Service 
request, the ME informs the SIM using TERMINAL RESPONSE (SS Return Result error code). 
$(Indication)$: If a null alpha identifier was provided by the SIM, the ME should not give any information to the 
user at the reception of a SS Return Result message; 

If the SS request is unsuccessfully received by the network, the ME shall inform the SIM using TERMINAL 
RESPONSE (network currently unable to process command), and not retry to send the request. 
$(Indication)$: If a null alpha identifier was provided by the SIM, the ME should not give any information to the 
user at the reception of a SS Return Result message. 

If the ME supports the Last Number Dialled service, the ME shall not store in EFlnd the supplementary service control 
string sent by the SIM in this command. 

6.4.12 SENDUSSD 

This subclause applies if $(SendUSSD)$ is supported. 

Upon receiving this command, the ME shall decide if it is able to execute the command. Examples are given below, but 
the list is not exhaustive: 

If the command is rejected because the ME is busy on a USSD transaction, the ME informs the SIM using 
TERMINAL RESPONSE (ME unable to process command - currently busy on USSD transaction); 

If the command is rejected because the ME is busy on a SS transaction, the ME informs the SIM using 
TERMINAL RESPONSE (ME unable to process command - currently busy on SS transaction); 

If the ME is able to send the USSD request, the ME shall: 

Send the USSD immediately, without need to alert the user first. 

$(release96)$: Optionally, the ME can give some audible or display indication concerning what is happening. 

$(begin$(Indication)$)$ 

Optionally, the SIM may include in this command an alpha-identifier. The use of this alpha-identifier by the ME 

is described below: 

If the alpha identifier is provided by the SIM and is not a null data object, the ME shall use it to inform the 
user. This is also an indication that the ME should not give any other information to the user on the fact that 
the ME is sending a USSD request. 

If the alpha identifier is provided by the SIM and is a null data object (i.e. length = '00' and no value part), 
this is an indication that the ME should not give any information to the user on the fact that the ME is sending 
a USSD request. 

If the alpha identifier is not provided by the SIM, the ME may give information to the user concerning what is 
happening. 

$(end$(Indication)$)$ 
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Once a USSD Return Result message not containing an error has been received from the network, the ME shall 
inform the SIM that the command has been successfully executed, using TERMINAL RESPONSE. This 
command shall include the contents of USSD Return Result as additional data. 

$(Indication)$: If a null alpha identifier was provided by the SIM, the ME should not give any information to the 
user at the reception of a USSD Return Result message; 

If the USSD operation is rejected because the network cannot support or is not allowing mobile initiated USSD, 
the ME informs the SIM using TERMINAL RESPONSE (USSD Return Result error code) 
$(Indication)$: If a null alpha identifier was provided by the SIM, the ME should not give any information to the 
user at the reception of a USSD Return Result message; 

If the USSD request is unsuccessfully received by the network, the ME shall inform the SIM using TERMINAL 
RESPONSE (network currently unable to process command), and not retry to send the request. 
$ (Indication) $: If a null alpha identifier was provided by the SIM, the ME should not give any information to the 
user at the reception of a USSD Return Result message. 

6.4.13 SET UP CALL 

Three types are defined: 

set up a call, but only if not currently busy on another call; 
set up a call, putting all other calls (if any) on hold; 
set up a call, disconnecting all other calls (if any) first. 

For each of these types, the SIM may request the use of an automatic redial mechanism according to the 

GSM 02.07 [19]. The SIM may also request an optional maximum duration for the redial mechanism. The ME shall 

attempt at least one call set-up. 

In addition to the called party number, the command may contain capability configuration parameters (giving the bearer 
capability to request for the call) and the called party subaddress. The ME shall use these in its call set-up request to the 
network. The command may also include DTMF digits, which the ME shall send to the network after the call has 
connected. It is possible for the SIM to request the ME to set up an emergency call by supplying the number "112" as 
called party number. If the SIM supplies a number stored in EFecc^ this shall not result in an emergency call. 

If the Fixed Dialling Number service is enabled, the number included in the SET UP CALL proactive command shall 
not be checked against those of the FDN list. 

Upon receiving this command, the ME shall decide if it is able to execute the command. Examples are given below, but 
the list is not exhaustive: 

If the command is rejected because the ME is busy on another call, the ME informs the SIM using TERMINAL 
RESPONSE (ME unable to process command - currently busy on call); 

If the command is rejected because the ME is busy on a SS transaction, the ME informs the SIM using 
TERMINAL RESPONSE (ME unable to process command - currently busy on SS transaction); 

If the command is rejected because the ME cannot support Call Hold, or because the ME does not support the 
capability configuration parameters requested by the SIM, the ME informs the SIM using TERMINAL 
RESPONSE (Command beyond ME's capabilities); 

If the command is rejected because the network cannot support or is not allowing Call Hold, the ME informs the 
SIM using TERMINAL RESPONSE (SS Return Result error code). 

If the ME is able to set up the call on the serving network, the ME shall: 

Alert the user (as for an incoming call). 

$(release96)$: Optionally, the ME can give some indication to the user concerning what is happening, perhaps 

using the alpha identifier in the command data from the SIM. 

$(begin$(Indication)$)$ 

Optionally, the SIM may include in this command an alpha-identifier. The use of this alpha-identifier by the ME 

is described below : 
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If the alpha identifier is provided by the SIM, the ME shall use it to inform the user, at the latest when the 
user is alerted. The ME may also use it to inform the user during the call set-up. 
$(end$(Indication)$)$; 

If the user accepts the call, the ME shall then set up a call to the destination address given in the response data, 
with the relevant capability configuration parameters and called party subaddress (if provided by the SIM); 

If the user does not accept the call, or rejects the call, then the ME informs the SIM using TERMINAL 
RESPONSE (user did not accept call set-up request). The operation is aborted; 

If $(ExtdRes)$ is supported and if the user has indicated the need to end the proactive SIM session, the ME shall 
send a TERMINAL RESPONSE with "Proactive SIM session terminated by the user" result value. 

Optionally, during call set-up, the ME can give some audible or display indication concerning what is happening; 

Once a CONNECT message has been received from the network (defined in GSM 04.08), the ME shall inform 
the SIM that the command has been successfully executed, using TERMINAL RESPONSE. Operation of the call 
then proceeds as normal. 

If the first call set-up attempt is unsuccessful: 

- If the SIM did not request redial then the ME shall inform the SIM using TERMINAL RESPONSE (network 
currently unable to process command), and not redial to set-up the call; 

If the SIM requested redial, then the ME may automatically redial the call (depending on its 
capability/configuration). In this case, the ME shall not send a command result to the SIM concerning the first or 
any subsequent failed set-up attempts. If the call set-up has not been successful, and the ME is not going to 
perform any more redials, or the time elapsed since the first call set-up attempt has exceeded the duration 
requested by the SIM, then the ME shall inform the SIM using TERMINAL RESPONSE (network currently 
unable to process command), and the redial mechanism shall be terminated; 

If the user stops the call set-up attempt or the redial mechanism before a result is received from the network, the 
ME informs the SIM using TERMINAL RESPONSE (user cleared down call before connection or network 
release). 

If the ME supports the Last Number Dialled service, the ME shall not store in EFlnd the call set-up details (called party 
number and associated parameters) sent by the SIM in this command. 

6.4.14 POLLING OFF 

This command disables the Proactive Polling (defined in GSM ILl 1 [20]). SIM Presence Detection (defined in GSM 
11.11 [20]) is not affected by this command. 

6.4.15 PROVIDE LOCAL INFORMATION 

This command requests the ME to send current local information to the SIM. At present, this information is restricted to: 

location information: the mobile country code (MCC), mobile network code (MNC), location area code (LAC) 
and cell ID of the current serving cell; 

- thelMEIoftheME; 

and, if $(NMR)$ is supported, the Network Measurement Results. 

The ME shall return the requested local information within a TERMINAL RESPONSE. Where location information has 
been requested and no service is currently available, then the ME shall return TERMINAL RESPONSE (ME currently 
unable to process command - no service). 

If $(NMR)$ is supported and the NMR are requested and a call is in progress, the value of all the returned parameters 
provided by the ME in the response to the command will be valid. However, if a call is not in progress (i.e. ME is in idle 
mode) some of the returned parameters (e.g. RXQUAL) may be invalid. 

NOTE: Network Measurement Results are defined in GSM 04.08 [8] as Measurement Results. 
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6.4.16 SET UP EVENT LIST 

This subclause applies only if $(Event)$ is supported. 

The SIM shall use this command to supply a set of events. This set of events shall become the current list of events for 
which the ME is to monitor. 

Any subsequent SET UP EVENT LIST command replaces the current list of events supplied in the previous SET UP 
EVENT LIST command. The SET UP EVENT LIST command can also be used to remove the entire list of events 
current in the ME; see sub-clause 6.6.16. The list of events provided by the SIM in the last SET UP EVENT LIST 
command shall be removed if the ME is powered off or the SIM is removed or electrically reset. 

When the ME has successfully accepted or removed the hst of events, it shall send TERMINAL RESPONSE (OK) to 
the SIM. 

When the ME is not able to successfully accept or remove the list of events, it shall send TERMINAL RESPONSE 
(Command beyond ME's capabilities). 

When one of the events in the current list occurs, then the ME shall use the Event Download mechanism to transfer 
details of the event to the SIM; see clause 10. 

6.5 Common elements in proactive SIM commands 

6.5.1 Command number 

The command number is to cater for the future possibility of multiple ongoing commands (i.e. when the SIM issues 
further commands before receiving the response to the ongoing command). The implications of such multiple ongoing 
commands have not been elaborated at this stage of the toolkit specification. 

Each command issued by a proactive SIM during a GSM session shall have its own command number. Command 
numbers may take any hexadecimal value between '01' and 'FE'. The command number is held in the command details 
data object. 

The SIM is responsible for assigning the command number. 

The ME shall keep a record of the status of each command and its command number, until the ME gives the result of the 
command to the SIM, using TERMINAL RESPONSE. After this, the ME may erase all internal records concerning this 
command. The command number is then free for allocation by the SIM to a new command. 

When the MS is powered off and on, the details of any ongoing command shall be reset. The ME shall not be expected 
to know the status of commands issued in a previous GSM session. 

6.5.2 Device identities 

This data object gives the devices which are the source and destination for the instruction. Only certain combinations of 
source and destination devices are allowed for each proactive command. These are given in clause 13 of this document. 

6.5.3 Alpha identifier 

$(release 96)$: Many of the commands include an alpha identifier data object. This is intended to be a short one or two 
word identifier for the ME to optionally display on screen along with any other indications, at the same time as the ME 
performs the SIM command. If longer text statements are required, which must be displayed on the screen, the SIM shall 
send a separate display command. 

$(Indication)$: Many of the commands include an alpha identifier data object. This is intended to be a short one or two 
word identifier which shall be displayed on screen by the ME at the same time as the SIM command is performed. If 
longer text statements are required, which must be displayed on the screen, the SIM shall send a separate display 
command. 
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6.6 Structure of proactive SIM commands 

The general structure of proactive SIM commands using TLV objects is described in annex D. 

6.6.1 DISPLAY TEXT 



6.6.2 



Description 


Section 


M/0 


Min 


Length! 


Proactive SIM command Tag 


13.2 


M 


Y 


1 


Length (A+B+C) 


- 


M 


Y 


1 or 2 


Command details 


12.6 


M 


Y 


A 


Device identities 


12.7 


M 


Y 


B 


Text string 


12.15 


M 


Y 


C 


GET INKEY 


Description 


Section 


M/0 


Min 


Length! 


Proactive SIIVI command Tag 


13.2 


M 


Y 


1 


Length (A+B+C) 


- 


M 


Y 


1 or 2 


Command details 


12.6 


M 


Y 


A 


Device identities 


12.7 


M 


Y 


B 


Text string 


12.15 


M 


Y 


C 



Text string 

Contents: text for the ME to display in conjunction with asking the user to respond. 

6.6.3 GET INPUT 



Description 


Section 


M/0 


Min 


Length 


Proactive SIM command Tag 


13.2 


M 


Y 


1 


Length (A+B+C+D) 


- 


M 


Y 


1 or 2 


Command details 


12.6 


M 


Y 


A 


Device identities 


12.7 


M 


Y 


B 


Text string 


12.15 


M 


Y 


C 


Response length 


12.11 


M 


Y 


D 


Default Text (only if $(DefChoice)$ is 
supported) 


12.23 





N 


E 



Text string 

Contents: text for the ME to display in conjunction with asking the user to respond. 

Response length 

Contents: the minimum and maximum acceptable lengths for the response from the user. 

Default Text (only if $(DefChoice)$ is supported) 

Contents: text for the ME to display if $(DefChoice)$ is supported, corresponds to a default text string offered by 

the SIM. 
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6.6.4 MORE TIME 



6.6.5 



Description 


Section 


M/0 


Min 


Length 


Proactive SIM command Tag 


13.2 


M 


Y 


1 


Length (A+B) 


- 


M 


Y 


1 or 2 


Command details 


12.6 


M 


Y 


A 


Device identities 


12.7 


M 


Y 


B 


PLAY TONE 


Description 


Section 


M/0 


Min 


Length 


Proactive SIIVI command Tag 


13.2 


M 


Y 


1 


Length (A+B+C+D+E) 


- 


M 


Y 


1 or 2 


Command details 


12.6 


M 


Y 


A 


Device identities 


12.7 


M 


Y 


B 


Alpha identifier 


12.2 





N 


C 


Tone 


12.16 





N 


D 


Duration 


12.8 





N 


E 



Tone 

Contents: the standard supervisory tone or proprietary ME tone that the ME shall generate, either on its own or 

on top of the downlink audio path. If no tone is specified, then the ME shall default to "general beep". 

NOTE: Some supervisory tones are optional for mobile equipment (see GSM 02.40 [18]). 

Duration 

Contents: the length of time for which the ME shall generate the tone, if the tone is continuous or repeatable. For 
single tones, the value of this data object shall be ignored by the ME. If no duration is specified, the ME shall 
default to a duration determined by the ME manufacturer. 

6.6.6 POLL INTERVAL 



Description 


Section 


M/0 


Min 


Length 


Proactive SIM command Tag 


13.2 


M 


Y 


1 


Length (A+B+C) 


- 


M 


Y 


1 or 2 


Command details 


12.6 


M 


Y 


A 


Device identities 


12.7 


M 


Y 


B 


Duration 


12.8 


M 


Y 


C 



Duration 

Contents: the maximum interval between two STATUS commands related to Proactive Polling. 
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6.6.7 SET-UP MENU 



Description 


Section 


M/0 


Min 


Length 


Proactive SIM command Tag 


13.2 


M 


Y 


1 


Length {A+B+C+D1+D2+...Dn+E) 


- 


M 


Y 


1 or 2 


Command details 


12.6 


M 


Y 


A 


Device identities 


12.7 


M 


Y 


B 


Alpha identifier 


12.2 


M 


Y 


C 


Item data object for item 1 


12.9 


M 


Y 


D1 


Item data object for item 2 


12.9 





N 


D2 




12.9 





N 


Dx 


Item data object for last item in list 


12.9 





N 


Dn 


Items Next Action Indicator (only if 
$(NextAction)$ is supported) 


12.24 





N 


E 



The SET-UP MENU command BER-TLV data object shall contain Item SIMPLE-TLV data objects. Each Item data 
object contains an item in the list, for the user to choose. The length of each Item data object may be different. Within a 
list, each Item shall have a unique item identifier. 



If the "Item data object for item 1" is a null data object (i.e. length = '00' and no value part), this is an indication to the 
ME to remove the existing menu from the menu system in the ME. 

If the SIM supports $(NextAction)$, it shall provide an Items Next Action Indicator data object with the comprehension 
required flag set to '0' . 



6.6.8 SELECT ITEM 



Description 


Section 


M/0 


Min 


Length 


Proactive SIIVI command Tag 


13.2 


M 


Y 


1 


Length {A+B+C+D1+D2+...Dn+E+F) 


- 


M 


Y 


1 or 2 


Command details 


12.6 


M 


Y 


A 


Device identities 


12.7 


M 


Y 


B 


Alpha identifier 


12.2 





N 


C 


Item data object for item 1 


12.9 


M 


Y 


D1 


Item data object for item 2 


12.9 





N 


D2 




12.9 





N 


Dx 


Item data object for last item in list 


12.9 





N 


Dn 


Items Next Action Indicator (only if 
$(NextAction)$ is supported) 


12.24 





N 


E 


Item Identifier $(Defltem)$ 


12.10 





N 


F 



The SELECT ITEM command BER-TLV data object shall contain Item SIMPLE-TLV data objects. Each Item data 
object contains an item in the list, for the user to choose. The length of each Item data object may be different. Within a 
list, each Item shall have a unique item identifier. If $(DefItem)$ is supported, the SELECT ITEM command BER-TLV 
data object may contain a single Item Identifier data object as an indication of the default item. The Comprehension 
Required flag in the Item Identifier data object shall be set to 0, indicating that it is not mandatory for the ME to support 
indication of the default item. 



If the SIM supports $(NextAction)$ it shall provide an Items Next Action Indicator data object with a comprehension 
required flag set to '0' . 
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6.6.9 SEND SHORT MESSAGE 



Description 


Section 


M/0 


Min 


Length 


Proactive SIM command Tag 


13.2 


M 


Y 


1 


Length (A+B+C+D+E) 


- 


M 


Y 


1 or 2 


Command details 


12.6 


M 


Y 


A 


Device identities 


12.7 


M 


Y 


B 


Alpha identifier 


12.2 





N 


C 


Address 


12.1 





N 


D 


SMS TPDU (SMS-SUBMIT or SMS- 
COMMAND) 


12.13 


M 


Y 


E 



The address data object holds the RP_Destination_Address of the Service Centre. If no RP_Destination_Address is 
transferred, then the ME shall insert the default Service Centre address. 



6.6.10 SENDSS 



Description 


Section 


M/0 


Min 


Length 


Proactive SIM command Tag 


13.2 


M 


Y 


1 


Length (A+B+C+D) 


- 


M 


Y 


1 or 2 


Command details 


12.6 


M 


Y 


A 


Device identities 


12.7 


M 


Y 


B 


Alpha identifier 


12.2 





N 


C 


SS string 


12.14 


M 


Y 


D 



6.6.11 SENDUSSD 

This subclause applies if $(SendUSSD)$ is supported. 



Description 


Section 


M/0 


Min 


Length 


Proactive SIM command Tag 


13.2 


M 


Y 


1 


Length (A+B+C+D) 


- 


M 


Y 


1 or 2 


Command details 


12.6 


M 


Y 


A 


Device identities 


12.7 


M 


Y 


B 


Alpha identifier 


12.2 





N 


C 


USSD String 


12.17 


M 


Y 


D 



6.6.12 SET UP CALL 



Description 


Section 


M/0 


Min 


Length 


Proactive SIM command Tag 


13.2 


M 


Y 


1 


Length (A+B+C+D+E+F+G) 


- 


M 


Y 


1 or 2 


Command details 


12.6 


M 


Y 


A 


Device identities 


12.7 


M 


Y 


B 


Alpha identifier 


12.2 





N 


C 


Address 


12.1 


M 


Y 


D 


Capability configuration parameters 


12.4 





N 


E 


Called party subaddress 


12.3 





N 


F 


Duration 


12.8 





N 


G 



If the capability configuration parameters are not present, the ME shall assume the call is a speech call. 

If the called party subaddress is not present, the ME shall not provide a called party subaddress to the network. 

If the duration is not present, the SIM imposes no restrictions on the ME of the maximum duration of redials. 
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6.6.13 REFRESH 



Description 


Section 


M/0 


Min 


Length 


Proactive SIM command Tag 


13.2 


M 


Y 


1 


Length (A+B+C) 


- 


M 


Y 


1 or 2 


Command details 


12.6 


M 


Y 


A 


Device identities 


12.7 


M 


Y 


B 


File List 


12.18 


M/0 


N 


C 



For the refresh modes "File Change Notification" and "SIM Initialization and File Change Notification", the SIM shall 
supply a File List data object, indicating which EFs need to be refreshed. For other modes, inclusion of a File List is 
optional, and the ME shall ignore it. 

6.6.14 POLLING OFF 



Description 


Section 


M/0 


Min 


Length 


Proactive SIM command Tag 


13.2 


M 


Y 


1 


Length (A+B) 


- 


M 


Y 


1 or 2 


Command details 


12.6 


M 


Y 


A 


Device identities 


12.7 


M 


Y 


B 



6.6.15 PROVIDE LOCAL INFORMATION 



Description 


Section 


M/0 


Min 


Length 


Proactive SIM command Tag 


13.2 


M 


Y 


1 


Length (A+B) 


- 


M 


Y 


1 or 2 


Command details 


12.6 


M 


Y 


A 


Device Identities 


12.7 


M 


Y 


B 



6.6.16 SET UP EVENT LIST 

This subclause applies if $(Event)$ is supported. 



Description 


Section 


M/0 


Min 


Length 


Proactive SIM command Tag 


13.2 


M 


Y 


1 


Length (A+B+C) 


- 


M 


Y 


1 or 2 


Command details 


12.6 


M 


Y 


A 


Device Identities 


12.7 


M 


Y 


B 


Event list 


12.25 


M 


Y 


C 



If the Event list is a null data object (i.e. length = '00' and no value part), this is an indication to the ME to remove the 
existing list of events in the ME. 



6.7 



Command results 



Once the ME has made its attempt to execute a proactive command from the SIM, the ME shall inform the SIM of the 
success or otherwise of that command, by using TERMINAL RESPONSE. This message gives the command details, 
including the number of the command (see subclause 6.5.1), a general result, and sometimes more specific information. 

Three overall categories of results are defined: 

Command performed successfully. This is returned by the ME for every successful command; 

Temporary problem with executing command. This is further defined below, but generally these indicate to the 
SIM that it is worth trying again later; 
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Permanent problem with executing command. These are further defined below, but generally indicate that the 
same command will end in the same result if repeated during the same GSM session. 

Successful commands are further defined as: 

Command performed successfully. There were no problems; 

Command performed with partial comprehension. Here the ME receives a command with one or more SIMPLE- 
TLV data objects that are unrecognized or unexpected, all of which do not have their "comprehension required" 
flag set (subclause 13.3), but the parent BER-TLV data object still has the minimum set of SIMPLE-TLV data 
objects required to perform the command; 

Command performed, with missing information. The ME received at least the minimum set of component parts, 
but did not receive all of the parts that it believed mandatory for the SIM to send. 

Temporary problems are further defined as: 

ME is currently unable to process the command. Specific causes for this are: 

the screen is busy; 

ME currently busy on a call; 

- ME currently busy on SS transaction; 

- ME currently busy on USSD operation; 
no service is currently available; 

access control class barred on serving network; 
no radio resource currently available; 
not in speech call. 

If none of these can be made to apply, a "no cause can be given" value can be used. 

Network is currently unable to process the command. Specific cause values are the cause values given by the 
network, as defined in GSM 04.08 [8]. 

The user did not accept the call set-up request. This is where the ME alerts the user before setting up a call, and 
the user either rejected or did not accept the "call". 

The user cleared down the call, before the call connected (CONNECT received from network, as defined in 
GSM 04.08 [8]) or before the network released the call. 

Permanent problems are further defined as: 

Command is beyond ME's capabilities. This is sent by the ME when it understands what the SIM is asking it to 
do, but does not have the capability to do it, e.g. ME which only supports SMS asked to set up a call. 

Command type not understood by ME. This is sent by the ME when the SIM sends a command with the Type of 
Command byte set to a value the ME does not know. This is to allow future expansion of commands. 

Command data not understood by ME. This is sent by the ME when the command type is understood by the ME, 
but the related data object(s) are not, e.g. reserved values have been included in a data object, or one or more 
unknown SIMPLE-TLV data objects have a "comprehension required" tag. 

SS Return Error. This is given to the SIM when the network returns a SS error in response to a previous SS 
command. Specific cause values are the same as given by the network in the Return Error message. 

USSD Return Error, if $(SendUSSD)$ is supported. This is given to the SIM when the network returns a USSD 
error in response to a previous USSD command. Specific cause values are the same as given by the network in a 
Return Error message. 

SMS RP-ERROR. This is given to the SIM when the network returns an error in response to the ME trying to 
send a short message. Specific cause values are the same as the cause value of RP-Cause in an RP-ERROR 
message. 

Error, required values are missing. This is given when the command type is understood by the ME, but it does 
not receive the minimum set of SIMPLE-TLV data objects that it requires to perform the command. These 
components are shown by the "Min" column in the command structure definitions. 
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6.8 



Structure of TERMINAL RESPONSE 



Direction: ME to SIM 

The command header is specified in GSM 11.11 [14]. Length (A+B+C+D+E+F+G) is indicated by P3 of the header. 

Command parameters/data: 



Description 


Section 


M/0 


Min 


Length 


Command details 


12.6 


M 


Y 


A 


Device identities 


12.7 


M 


N 


B 


Resuit 


12.12 


M 


Y 


C 


Duration (only required in response to a 
POLL INTERVAL proactive command) 


12.8 


M/0 


Y/N 


D 


Text string (only required in response to a 
GET INKEY or GET INPUT or SEND USSD, 
if $(SendUSSD)$ is supported, proactive 
command) 


12.15 


M/0 


Y/N 


E 


Item identifier (only required in response to 
SELECT ITEIVI proactive command) 


12.10 


M/0 


Y/N 


F 


Local information (only required in response 
to PROVIDE LOCAL INFORMATION 
proactive command) 


12.19 

/1 2.20 

/and, if 

$(NMR)$is 

supported, 

12.22 


M/0 


Y/N 


G 



Command details: this data object shall be identical to the command details data object (including the 
comprehension required flag) given by the SIM in the proactive command to which the ME is giving the result. 

If the ME has not received a valid Command number, all Command Details object values shall be set to '00' and 
the Result shall indicate an error. 

If the failure is caused by a problem on the transmission layer, the ME shall repond with "temporary problem" 
("ME currently not able to process command"). If not, the ME shall respond with "permanent problem" (either 
"command not understood by ME" or "Error required values are missing"). 

The SIM shall interpret a Terminal Response with a command number '00' as belonging to the last proactive 
command having been sent to the ME. 

Device identities: the ME shall set the device identities to: 
Source: ME 

Destination: SIM 

Result: This data object holds the result of the proactive SIM command. 

Duration: When the ME issues a successful TERMINAL RESPONSE for a POLL INTERVAL command, it shall 
state the polling interval it will be using in the Duration data object. All other types of TERMINAL RESPONSE 
do not need to include Duration. If one is included by the ME, the SIM shall ignore it. 

Text string: When the ME issues a successful TERMINAL RESPONSE ('OX' result value - refer to subclause 
1 1 . 12) for a GET INKEY or GET INPUT or SEND USSD (if $(SendUSSD)$ is supported) command, it shall 
supply the single character or the character string entered by the user in the Text string data object, or the text 
returned within the Return Result message from the network for the USSD command, no matter what type of 
string was entered. All other types of TERMINAL RESPONSE do not need to include Text string. If one is 
included by the ME, the SIM shall ignore it. 

Item identifier: When the ME issues a successful TERMINAL RESPONSE ('OX' result value - refer to subclause 
11.12) for a SELECT ITEM command, it shall supply the identifier of the item selected by the user in the Item 
identifier data object. All other types of TERMINAL RESPONSE do not need to include Item identifier. If one is 
included by the ME, the SIM shall ignore it. 

Local information. When the ME issues a successful TERMINAL RESPONSE for a PROVIDE LOCAL 
INFORMATION command, it shall supply the requested local information. 
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- Where the SIM has requested location information, TERMINAL RESPONSE shall contain the location 
information data object. All other types of TERMINAL RESPONSE do not need to include location 
information. If one is included by the ME, the SIM shall ignore it. 

- Where the SIM has requested the IMEI, TERMINAL RESPONSE shall contain the IMEI data object. All 
other types of TERMINAL RESPONSE do not need to include IMEI information. If one is included by the 
ME, the SIM shall ignore it. 

- If $(NMR)$ is supported: Where the SIM has requested the Network Measurement Results the TERMINAL 
RESPONSE shall contain the NMR data object. All other types of TERMINAL RESPONSE do not need to 
include the NMR information. If one is included by the ME, the SIM shall ignore it. 

Under no circumstances shall the SIM wait indefinitely for a TERMINAL RESPONSE. 

Any future additional SIMPLE- TLV objects shall be included as Min = N and comprehension not required. This 
will ensure that any proactive command will end in a predictable way. 

Response parameters/data: None. 

6.9 Proactive SIM session and IVIE display interaction 

During a proactive session the ME display shall be refreshed by any display data contained in the first and each 
subsequent proactive command. The refresh shall occur once the ME has retrieved the proactive command using the 
Fetch instruction, following the proactive command pending status response. 

If no proactive command is pending (status response of '90 00' following the Terminal Response), then the session 
releases the display back into ME control. If this session was terminated in a backwards move, and the session was 
initiated from an Envelope command containing a Menu Selection, it is recommended that the display returns to the 
Setup Menu. 

6.10 Handling of unknown, unforeseen and erroneous messages 

6.10.1 General 

The procedures described in this subclause apply to the BER-TLV and SIMPLE-TLV data objects described in this TS. 
The purpose of this subclause is to allow greater flexibility in future versions of this document, and a greater 
predictability across different versions of this standard. 

The procedures described here specify how the ME and SIM shall behave when they receive a proactive command or 
response that is not fully compliant with the standards by which it was designed. A response will be made to the SIM by 
means of the "general result" field of the "result" 

If the ME sends a TERMINAL RESPONSE to the SIM that contains values that the SIM does not understand, then the 
SIM shall issue the appropriate SWl / SW2 error response. The current proactive transaction shall be considered 
complete and neither the ME or the SIM shall take no further action with regard to it. In this case, unless the "General 
result" is "command performed..." then the SIM shall assume that the command was not carried out and that a 
permanent error exists with regard to that particular proactive command. If the command was performed, but the 
"additional information on result" field was not understood, then the SIM may attempt the command again at a later 
stage in the current GSM session. 

If the SIM has enough information to proceed (i.e. it has received all the data objects of the Minimum set) then it shall 
do so. 

6.1 0.2 Message too short 

Any information received that is not a complete tag and length shall be ignored. 
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6.10.3 Missing minimum information 

If a message is received that does not have all the mandatory elements in it, then if all of the minimum set elements are 
present then the receiver shall complete the command and report "command performed, with missing information". 

If the minimum set of elements is not complete, then the ME shall respond with "Error, required values are missing". 



6.10.4 Unl^nown Tag value 



If a BER-TLV object is received that has a tag that is understood, but contains SIMPLE-TLV components that have 
unknown tags, then provided the minimum set condition is fulfilled, the "comprehension required" bit of the tag shall 
determine how the receiving entity behaves. 

If the comprehension required flag in an unknown tag is set to T, and the ME either does not recognize or is not 
expecting one or more of the SIMPLE-TLV objects in the message, then it shall respond with "Command data not 
understood by ME". 

If the comprehension required flag is set to '0', then the ME shall read the length field that follows and ignore that object. 
In this case the ME will be able to carry out the command without the SIMPLE-TLV components that it cannot 
understand. It shall respond with "command performed, with missing information". 



6. 1 0.5 Unexpected Tag value 



If a BER-TLV object is received that contains elements that have recognisable tags, but which where not expected in the 
context of this message (for example, the ME sees SMS TDPU tag as part of TEXT FOR DISPLAY), then is shall 
discard that element. It shall then proceed as described for Unknown Tag values. 

If a received object has a tag that has already been received, then the first instance shall be used and any subsequent 
instances shall be discarded. 



6.10.6 Length errors 

If the total lengths of the SIMPLE-TLV data objects are not consistent with the length given in the BER-TLV data 
object, then the whole BER-TLV data object shall be rejected. The result field in the TERMINAL RESPONSE shall 
have the error condition "Command data not understood by ME". 

If the length of the BER-TLV data object is shorter than the length of the response data, the ME shall ignore response 
data following the complete BER-TLV data object. If the length of the BER-TLV data object is longer than the length of 
the response data, then sections 6.10.2. and 6.10.3 apply. 

6.10.7 Contents not understood 

If the contents of a SIMPLE-TLV data object contains a field with a value that is defined as reserved, then the whole 
SIMPLE-TLV data object shall be considered as invalid. It will then depend on the "comprehension required" bit of the 
relevant tag as to whether the whole BER-TLV data object shall be rejected, or whether that particular SIMPLE-TLV 
data object shall be ignored. 

If the contents of a BER-TLV object contains RFU bits or bytes, then these shall be ignored. 



6.1 0.8 Extended length data objects 



If a SIMPLE-TLV data object has a length longer than expected (i.e. more information has been added), then the 
receiver shall ignore this extra information to the end of the object. The end of the object shall be found by looking at 
the "length" field of that object. 

NOTE: If comprehension of the extra bytes is required, this can be achieved by the use of a reserved coding in an 
earlier field. 
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6.1 1 Proactive commands versus possible Terminal response 

The following table shows for each proactive command the possible terminal response returned (marked by a "•" character). 





Proactive Command | 




GET 
INKEY 


GET 
INPUT 


SELECT 
ITEM 


PLAY 
TONE 


DIS- 
PLAY 
TEXT 


SETUP 
MENU 


POLL- 
ING OFF 


POLL 
INTER- 
VAL 


RE- 
FRESH 


SETUP 
CALL 


SEND 
SMS 


SEND 
SS 


SEND 
USSD 


PRO- 
VIDE 
LOCAL 
INFO 


MORE 
TIME 


Terminal response 


00 


Command performed successfully 


• 


• 


• 


• 


• 


• 


• 


• 


• 


• 


• 


• 


• 


• 


• 


01 


Command performed with partial 
comprehension 


• 


• 


• 


• 


• 


• 


• 


• 


• 


• 


• 


• 


• 


• 


• 


02 


Command performed, with missing 
information 


• 


• 


• 


• 


• 


• 


• 


• 


• 


• 


• 


• 


• 


• 


• 


03 


REFRESH performed with additional 
EFs read 


















• 














10 


Proactive SIM session terminated by 
the user 


• 


• 


• 


• 


• 










• 












11 


Backward move in the proactive SIM 
session requested by the user 


• 


• 


• 




• 






















12 


No response from user 


• 


• 


• 




• 






















13 


Help information required by the user, 
if Helplnfo is supported 


• 


• 


• 


























20 


ME currently unable to process 
command 


• 


• 


• 


• 


• 


• 


• 


• 


• 




• 


• 


• 


• 


• 


21 


Network currently unable to process 
command 
























• 


• 






22 


User did not accept call setup request 
































23 


User cleared down call before 
connection or network release 
































30 


Command beyond MEs capabilities 


• 


• 


• 


• 


• 


• 


• 


• 


• 




• 




• 


• 


• 


31 


Command type not understood by ME 


• 


• 


• 


• 


• 


• 


• 


• 


• 




• 




• 


• 


• 


32 


Command data not understood by ME 


• 


• 


• 


• 


• 


• 


• 


• 


• 




• 




• 


• 


• 


33 


Command number not known by ME 


• 


• 


• 


• 


• 


• 


• 


• 


• 




• 




• 


• 


• 


34 


SS Return Error 
































35 


SMS RPERROR 






















• 










36 


Error, required values are missing 


• 


• 


• 


• 


• 


• 


• 


• 


• 


• 


• 


• 


• 


• 


• 


37 


USSD return error 


























• 
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Data download to SIM 



7.1 



SMS-PP data download 



7.1.1 Procedure 

If the service "data download via SMS Point-to-point" is allocated and activated in the SIM Service Table (see 
GSM 11.11 [14]), then the ME shall follow the procedure below: 

- When the ME receives a Short Message with: 

protocol identifier = SIM data download, and 

data coding scheme = class 2 message, 

then the ME shall pass the message transparently to the SIM using the ENVELOPE (SMS-PP DOWNLOAD) command 
as defined below. 

The ME shall not display the message, or alert the user of a short message waiting. 

- The ME shall wait for an acknowledgement from the SIM. The SIM shall respond with SWl / SW2 = '90 00', '91 XX' or 
'9F XX'. 

If the SIM responds with '90 00' or '91 XX', the ME shall acknowledge the receipt of the short message to the network. 

- If the SIM responds with '9F XX', the ME shall use the GET RESPONSE command to get the response data. The 
response data from the SIM will be supplied by the ME in the TP-User-Data element of the RP-ACK message it will 
send back to the network (see GSM 03.40 [6] and GSM 04.11 [9]). The values of protocol identifier and data coding 
scheme in RP-ACK shall be as in the original message. 

If the service "data download via SMS-PP" is not allocated and activated in the SIM Service Table, and the ME receives a 
Short Message with the protocol identifier = SIM data download and data coding scheme = class 2 message, then the ME shall 
store the message in EFjjy,^ in accordance with GSM 11.11 [14]. 

NOTE: MEs not supporting SIM Application Toolkit are likely to store data download messages in EF^jyjg, as if they 
were normal short messages. 

7.1 .2 Structure of ENVELOPE (SMS-PP DOWNLOAD) 

Direction: ME to SIM 

The command header is specified in GSM 11.11 [14]. 

Command parameters/data: 



Description 


Section 


M/0 


Min 


Length 


SMS-PP download tag 


13.1 


M 


Y 


1 


Length (A+B+C) 


- 


M 


Y 


1 or 2 


Device identities 


12.7 


M 


Y 


A 


Address 


12.1 





N 


B 


SMS TPDU (SMS-DELIVER) 


12.13 


M 


Y 


C 



Device identities: the ME shall set the device identities to: 
Source: Network 

Destination: SIM 

Address: The address data object holds the RP_Originating_Address of the Service Centre (TS-Service-Centre- 
Address), as defined in GSM 04.1 1 [9]. 
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Response parameters/data: 

It is permissible for the SIM not to provide response data. If the SIM responds with '90 00' then no response parameter shall be 
available, otherwise the SIM shall respond with '9F XX' and the following data is returned: 



7.2 



Byte(s) 


Description 


Length 


1-X(X<128) 


SIM Acknowledgement 


X 



Cell Broadcast data download 



7.2.1 Procedure 

If the service "data download via SMS-CB" is allocated and activated in the SIM Service Table (see GSM 11.11 [14]), then the 
ME shall follow the procedure below: 

When the ME receives a new Cell Broadcast message, the ME shall compare the message identifier of the Cell 
Broadcast message with the message identifiers contained in EF(-.g]y[j£). 

If the message identifier is found in EF(-;g]^jQ, the cell broadcast page is passed to the SIM using the ENVELOPE 
(CELL BROADCAST DOWNLOAD) command, defined below. The ME shall not display the message. 

If the message identifier of the incoming cell broadcast message is not found in EFf^gj^jp, then the ME shall determine 
if the message should be displayed, by following the procedures in GSM 03.41 [7] and GSM 11.11 [14]. 

The ME shall identify new cell broadcast pages by their message identifier, serial number and page values. 

7.2.2 Structure of ENVELOPE (CELL BROADCAST DOWNLOAD) 

Direction: ME to SIM 

The command header is specified in GSM 11.11 [14]. 

Command parameters/data: 



Description 


Section 


M/0 


Min 


Length 


Cell Broadcast Download tag 


13.1 


M 


Y 


1 


Length (A+B) 


- 


M 


Y 


1 or 2 


Device identities 


12.7 


M 


Y 


A 


Cell Broadcast page 


12.5 


M 


Y 


B 



Device identities: the ME shall set the device identities to: 
Source: Network 

Destination: SIM 

Response parameters/data: None for this type of ENVELOPE command. 



8 



Menu Selection 



A set of possible menu options can be supplied by the SIM using the proactive command SET UP MENU. If the SIM has sent 
this command, and the user subsequently chooses an option or, if $(HelpInfo)$ is supported, the user requests help on it, the 
ME informs the SIM using this procedure. 



8.1 



Procedure 



If the service "menu selection" is allocated and activated in the SIM Service Table (see GSM 11.11 [14]), then the ME shall 
follow the procedure below. 
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- When the ME receives a menu selection from one of the menu items defined by a "SET-UP MENU" command issued 
previously by the SIM, or, if $(HelpInfo)$ is supported, the user has indicated the need to get help information on one of 
these menu items, then it shall pass the identifier of the selected menu item to the SIM using the EN VELOPE( MENU 
SELECTION) command, as defined below. 

8.2 Structure of ENVELOPE (MENU SELECTION) 

Direction: ME to SIM 

The command header is specified in GSM 11.11 [14]. 

Command parameters/data: 



Description 


Section 


M/0 


Min 


Lengtii 


Menu Selection tag 


13.1 


M 


Y 


1 


Length (A+B+C) 


- 


M 


Y 


1 or 2 


Device identities 


12.7 


M 


Y 


A 


Item identifier 


12.10 


M 


Y 


B 


Help request (if ${Helplnfo)$ is supported) 


12.21 





N 


C 



Device identities: the ME shall set the device identities to: 
Source: Keypad 

Destination: SIM 

Help request (if $(HelpInfo)$ is supported): inclusion of this data object depends upon whether the user actually 
selected the named menu item or just requested help information on it. If the user actually selected the menu item, this 
data object shall not be included. If the user indicated the need to get help information on the menu item, this data object 
shall be included. 

Response parameters/data: None for this type of ENVELOPE command. 



Gall Control by SIM 



9.1 Procedure for mobile originated calls 

If the service "call control" is allocated and activated in the SIM Service Table (see GSM 11.11 [14]), then the ME shall follow 
the procedure below: 

For all call set-up attempts (even those resulting from a SET UP CALL proactive SIM command, or those occurring 
when another call is already in progress), the ME shall first pass the call set-up details (dialled digits and associated 
parameters) to the SIM, using the ENVELOPE (CALL CONTROL) command defined below. If $(CellidCC)$ is 
supported, the ME shall also pass to the SIM in the ENVELOPE (CALL CONTROL) command the current serving cell. 
One exception is for the ME managing automatic redial attempts, for which the ME is required to pass the call set-up 
details to the SIM for the first attempt only. The only other exception is for the user dialling "112" or an emergency call 
code stored in EFecc^ for which the ME sets up an emergency call instead of passing the call set-up details to the SIM. 

- The SIM shall respond with S W 1 / S W2 = '90 00' or '9F XX'. 

- If the SIM responds with '90 00', the ME shall set up the call with the dialled digits and other parameters as sent to the 
SIM. 

- If the SIM responds with '9F XX', the ME shall use the GET RESPONSE command to get the response data. The 
response data from the SIM shall indicate to the ME whether to set up the call as proposed, not set up the call, set up a 
call using the data supplied by the SIM, or instead send a supplementary service or USSD operation using the data 
supplied by the SIM. It is mandatory for the ME to perform the call set-up request and the supplementary service or 
USSD operation in accordance with the data from the SIM. It is possible for the SIM to request the ME to set up an 
emergency call by supplying the number "112" as the response data. If the SIM supplies a number stored in EFecc, this 
shall not result in an emergency call. 
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$(release 96)$: Optionally, the ME may indicate to the user that the call has been barred, changed, or replaced by a 
supplementary service or USSD operation. 

If the ME supports the Last Number Dialled service, the ME shall update EFlnd with the call set-up details (digits string and 
associated parameters) corresponding to the initial user request. 

The ME shall then follow the call set-up procedure defined in GSM 04.08 [8] or the supplementary service or USSD operation 
procedure defined in GSM 04.80 [10]. 

9.2 Procedure for Supplementary Services and USSD 

If the service "call control" is allocated and activated in the SIM Service Table (see GSM 11.11 [14]), then for all 
supplementary service and USSD operations (including those resulting from a SEND SS or SEND USSD proactive SIM 
command), the ME shall first pass the supplementary service or USSD control string (corresponding to the supplementary 
service or USSD operation and coded as defined in GSM 02.30 [4], even if this SS or USSD operation has been performed via 
a specific menu of the ME) to the SIM, using the ENVELOPE (CALL CONTROL) command defined below. If $(CellidCC)$ 
is supported, the ME shall also pass to the SIM in the ENVELOPE (CALL CONTROL) command the current serving cell. 

The SIM shall respond in the same way as for mobile originated calls. The ME shall interpret the response as follows: 

If the SIM responds with '90 00', the ME shall send the supplementary service or USSD operation with the information 
as sent to the SIM. 

- If the SIM responds with '9F XX', the ME shall use the GET RESPONSE command to get the response data. The 
response data from the SIM shall indicate to the ME whether to send the supplementary service or USSD operation as 
proposed, not send the SS or USSD operation, send the SS or USSD operation using the data supplied by the SIM, or 
instead set up a call using the data supplied by the SIM. It is mandatory for the ME to perform the supplementary 
service or USSD operation or the call set-up request in accordance with the data from the SIM. 

$(release96)$: Optionally, the ME may indicate to the user that the supplementary service or USSD operation has been barred, 
changed, or replaced by a call set-up request. 

If the ME supports the Last Number Dialled service, the ME shall update EFlnd with the supplementary service or USSD 
control string corresponding to the initial user request. 

The ME shall then follow the supplementary service or USSD operation procedure defined in GSM 04.80 [10] or the call set- 
up procedure defined in GSM 04.08 [8]. 

9.3 Indication to be given to the user 

This entire subclause applies only if $(Indication)$ is supported. 

The SIM may optionally include an alpha-identifier in the response data to the ENVELOPE (CALL CONTROL) message, in 
order to inform the user at the time the response is received by the ME. The use of this alpha identifier by the ME is described 
below : 

if the SIM responds with "allowed, no modification", then : 

if the alpha identifier is provided by the SIM and is not a null data object, the ME shall use it to inform the user 
during the call set-up; 

if the alpha identifier is provided by the SIM and is a null data object (i.e. length = '00' and no value part), this is an 
indication that the ME should not modify the display corresponding to the initial user request; 

if the alpha identifier is not provided by the SIM, the ME may give information to the user concerning what is 
happening; 

if the SIM responds with "not allowed", then: 

if the alpha identifier is provided by the SIM and is not a null data object, the ME shall use it to inform the user. This 
is also an indication that the ME should not give any other information to the user on the reason of the barring; 
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if the alpha identifier is provided by the SIM and is a null data object (i.e. length = '00' and no value part), the ME 
may give information to the user concerning what is happening; 

if the alpha identifier is not provided by the SIM, the ME may give information to the user concerning what is 
happening. 

if the SIM responds with "allowed, with modifications", then : 

if the alpha identifier is provided by the SIM and is not a null data object, the ME shall use it to inform the user. The 
ME shall then not display the destination address or SS string given by the SIM. This is also an indication that the 
ME should not give any other information to the user on the changes made by the SIM to the initial user request; 

if the alpha identifier is provided by the SIM and is a null data object (i.e. length = '00' and no value part), this is an 
indication that the ME should not give any information to the user on the changes made by the SIM to the initial user 
request. The ME shall not display the destination address or SS string given by the SIM. The ME should not modify 
the display corresponding to the initial user request; 

if the alpha identifier is not provided by the SIM, the ME may indicate to the user that the initial user request has 
been changed. 

9.4 Interaction with Fixed Dialling Number 

It is permissible for the Fixed Dialling Number service to be enabled (see GSM 11.11 [14]) at the same time as Call Control is 
allocated and activated in the SIM Service Table. 

If FDN is enabled and Call Control is activated, the ME shall follow this procedure: 

The ME shall check that the number (or the supplementary service control string) entered through the MMI is on the 
FDN list, in accordance with GSM 02.07 [19]. 

If the MMI input does not pass the FDN check, the call (or the supplementary service operation) shall not be set up. 

If the MMI input does pass the FDN check, the ME shall pass the dialled digits (or the supplementary service control 
string) and other parameters to the SIM, using the ENVELOPE (CALL CONTROL) command. 

If the SIM responds with "allowed, no modification", the ME shall set up the call (or the supplementary service 
operation) as proposed. 

If the SIM responds with "not allowed", the ME shall not set up the call (or the supplementary service operation). 

If the SIM responds with "allowed with modifications", the ME shall set up the call (or supplementary service 
operation) in accordance with the response from the SIM. If the modifications involve changing the dialled digits (or the 
supplementary service control string), the ME shall not re-check this modified number (or string) against the FDN list. 

If the user wishes to enable or disable Fixed Dialling Number, the ME shall follow the procedure in GSM 11.11 [14]. The state 
of the Call Control service shall have no effect on this procedure. 

9.5 Support of Barred Dialling Number (BDN) service 

The BDN service shall be allocated and activated in the SIM Service Table only if Call Control is also allocated and activated 
in the SIM Service Table. 

If Barred Dialling Number service is enabled (see GSM 11.11 [14]), when receiving the dialled number (or supplementary 
service control string) and other parameters from the ME, the SIM may check this information against those stored in EFg^j^ 
(examples of comparison methods are given in GSM 02.07 [19]). 

If the SIM responds with "not allowed" (e.g., a match is made against a BDN), the ME shall not set up the call (or the 
supplementary service operation). 

If the SIM responds with "allowed, no modification", the ME shall set up the call (or the supplementary service 
operation) as proposed. 
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If the SIM responds with "allowed with modifications", the ME shall set up the call (or the supplementary service 
operation) in accordance with the response from the SIM. If the modifications involve changing the dialled number (or 
the supplementary service control string), the ME shall not re-check this modified number (or string) against the FDN 
list when FDN is enabled. 

If the user wishes to enable or disable Barred Dialling Number, the ME shall follow the procedure in GSM 11.11 [14]. 

9.6 Structure of ENVELOPE (CALL CONTROL) 

Direction: ME to SIM 

The command header is specified in GSM 11.11 [14]. 

Command parameters/data: 



Description 


Section 


M/0 


Min 


Length 


Call control tag 


13.1 


M 


Y 


1 


Length (A+B+C+D). 

If $(cellidCC)$ is supported, then Length 

(A+B+C+D+E) 




M 


Y 


1 or 2 


Device identities 


12.7 


M 


Y 


A 


Address 
or 

SS string 


12.1 

or 

12.14 


M 


Y 


B 


Capability configuration parameters 


12.4 





N 


C 


Called party subaddress 


12.3 





N 


D 


$(cellidCC)$ : Location information 


12.19 


M 


N 


E 



Device identities: the ME shall set the device identities to: 
Source: ME 

Destination: SIM 

Address or SS string : only one data object shall be sent to the SIM. 

For a call set-up, the address data object is used and holds the Called Party Number, as defined in GSM 04.08 [8], to 
which the ME is proposing setting up the call. 

For a supplementary service or USSD operation, the SS string data object is used and holds the corresponding 
supplementary service or USSD control string. 

Capability configuration parameters: Only used for a call set-up, this contains the Bearer capabilities that the ME is 
proposing to send to the network. If this data object is not present, this shall indicate a speech call. 

Called party subaddress: Only used for a call set-up, this contains the called party subaddress that the ME is proposing 
to send to the network. If one is not present, this shall indicate that the ME is proposing not to send this information 
element to the network. 

Location information: If $(CellidCC)$ is supported, this data object contains the identification (MCC, MNC, LAC, Cell 
Identity) of the current serving cell of the MS. The comprehension required flag of this data object in this command 
shall be set to '0'. 

Response parameters/data: 

It is permissible for the SIM to provide no response data, by responding with SWl / SW2 = '90 00'. If the SIM does not provide 
any response data, then this shall have the same meaning as "allowed, no modification". 
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Description 


Section 


M/0 


Min 


Length 


Call control result 


- 


M 


Y 


1 


Length (A+B+C) 

$(lndication)$: Length (A+B+C+D) 


- 


M 


Y 


1 or 2 


Address 
or 

SS string 


12.1 

or 

12.14 





N 


A 


Capability configuration parameters 


12.4 





N 


B 


Called party subaddress 


12.3 





N 


C 


$(lndication)$: Alpha identifier 


12.2 





N 


D 



- Call control result: 

Contents: the command that the SIM gives to the ME concerning whether to allow, bar or modify the proposed call (or 
supplementary service operation). 

Coding: 

'00' = Allowed, no modification 

'01' = Not allowed 

'02' = Allowed with modifications 

Address or SS string : Only one data object may be included if the SIM requests the call (or supplementary service or 
USSD operation) details to be modified. 

For a call set-up, if the address data object is not present, then the ME shall assume the Dialling number is not to be 
modified. 

For a supplementary service or USSD operation, if the SS string data object is not present, then the ME shall assume 
that SS or USSD operation is not to be modified. 

Capability configuration parameters: Only used for a call set-up, this data object is only required if the SIM requests the 
call details to be modified. If the capability configuration parameters are not present, then the ME shall assume the 
parameters are not to be modified. 

Called party subaddress: Only used for a call set-up, this data object is only required if the SIM requests the call details 
to be modified. If the called party subaddress is not present, then the ME shall assume the subaddress is not to be 
modified. If the subaddress supplied by the SIM is a null data object, then the ME shall not provide a called party 
subaddress to the network. A null data object shall have length = '00' and no value part. 

$(Indication)$: Alpha identifier: this data object is only required if the SIM requests a particular indication to be given 
to the user. The handling of this data object by the ME is described in section 9.3. The comprehension required flag of 
this data object shall be set to '0'. 

It is mandatory for the SIM to provide at least one of the optional data objects if it has set the Call control result to "allowed 
with modifications". 



1 MO Short Message Control by SIM 

This entire clause applies only if $(MOSMcontrol)$ is supported. 



10.1 Description 



If the service "MO Short Message Control" is allocated and activated in the SIM Service Table (see GSM 11.11 [14]), then the 
ME shall follow the procedure below: 

For all MO short message attempts (even those resulting from a SEND SM proactive SIM command), the ME shall first 
pass the RP_destination_address of the service center and the TP_Destination_Address to the SIM, using the 
ENVELOPE (MO SHORT MESSAGE CONTROL) command defined below. The ME shall also pass to the SIM in the 
ENVELOPE (MO SHORT MESSAGE CONTROL) command the current serving cell 

- The SIM shall respond with S W 1 / SW2 = '90 00' or '9F XX'. 



GSM 11.14 version 6.0.0 GSM Release 1997 



46 



TS 101 267 V6.0.0 (1998-04) 



If the SIM responds with '90 00', the ME shall send the short message with the addresses unchanged. 

- If the SIM responds with '9F XX', the ME shall use the GET RESPONSE command to get the response data. The 
response data from the SIM shall indicate to the ME whether to send the short message as proposed, not send the short 
message or send a short message using the data supplied by the SIM. It is mandatory for the ME to perform the MO 
short message request in accordance with the data from the SIM. 

The ME shall then follow the MO Short Message procedure defined in GSM 04.1 1 [9]. 

1 0.2 Structure of ENVELOPE (MO SHORT MESSAGE CONTROL) 

Direction: ME to SIM 

The command header is specified in GSM 11.11 [14]. 

Command parameters/data: 



Description 


Section 


M/0 


Min 


Length 


MO Short Message control tag 


13.1 


M 


Y 


1 


Length (A+B+C+D) 


- 


M 


Y 


1 or 2 


Device identities 


12.7 


M 


Y 


A 


Address data object 1 


12.1 


M 


Y 


B 


Address data object 2 


12.1 


M 


Y 


C 


Location information 


12.19 


M 


Y 


D 



Device identities: the ME shall set the device identities to: 
Source: ME 

Destination: SIM 

Address data object 1 : this adress data object 1 contains the RP_Destination_Address of the Service Center to which 
the ME is proposing to send the short message. 

Address data object 2 : this adress data object 2 contains the TP_Destination_Address to which the ME is proposing to 
send the short message. 

Location information : this data object contains the identification (MCC, MNC, LAC, Cell Identity) of the current 
serving cell of the MS. 

Response parameters/data: 

It is permissible for the SIM to provide no response data, by responding with SWl / SW2 = '90 00'. If the SIM does not provide 
any response data, then this shall have the same meaning as "allowed, no modification". 



Description 


Section 


M/0 


Min 


Length 


MO short message control result 


- 


M 


Y 


1 


Length (A+B) 

$(lndication)$: Length (A+B+C) 


- 


M 


Y 


1 or 2 


Address data object 1 


12.1 





N 


A 


Address data object 2 


12.1 





N 


B 


$(lndication)$: Alpha identifier 


12.2 





N 


C 



- MO Short Message control result: 

Contents: the command that the SIM gives to the ME concerning whether to allow, bar or modify the proposed short 

message. 



Coding: 



'00' = Allowed, no modification 

'01' = Not allowed 

'02' = Allowed with modifications 

Address data object 1: if the address data object 1 is not present, then the ME shall assume the RP_Destination_Address 
of the Service Center is not to be modified. 
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Address data object 2: if the address data object 2 is not present, then the ME shall assume the TP_Destination_Address 
is not to be modified. 

$(Indication)$: Alpha identifier: this data object is only required if the SIM requests a particular indication to be given 
to the user. The handling of this data object by the ME is described in section 10.3. 

The SIM shall provide the two optional address data objects if it has set the MO Short Message control result to "allowed with 
modifications". 

1 0.3 Indication to be given to the user 

This entire subclause applies only if $(Indication)$ is supported. 

The SIM may optionally include an alpha-identifier in the response data to the ENVELOPE (MO SHORT MESSAGE 
CONTROL) message, in order to inform the user at the time the response is received by the ME. The use of this alpha identifier 
by the ME is identical to the one described in section 9.3 relative to call control by SIM. 

1 1 Event download (if $(Event)$ is supported) 

A set of events for the ME to monitor can be supplied by the SIM using the proactive command SET UP EVENT LIST. If the 
SIM has sent this command, and an event which is part of the list subsequently occurs, the ME informs the SIM using the 
procedure below, relevant for that event. 

Processing within the ME resulting from this event shall proceed as normal, independent of sending the ENVELOPE command 
to the SIM. 

Where events occur while the SIM-ME interface is already busy, the ME shall queue events and send event download messages 
to the SIM in the order in which they occurred. 

11.1 MT call event 

11.1.1 Procedure 

If the MT call event is part of the current event list (as set up by the last SET UP EVENT LIST command, see section 6.4.16), 
then when the ME receives an incoming SETUP message, the ME shall inform the SIM that this has occurred, by using the 
ENVELOPE (EVENT DOWNLOAD - MT call) command as defined below. 

1 1 .1 .2 Structure of ENVELOPE (EVENT DOWNLOAD - MT call) 

Direction: ME to SIM 

The command header is specified in GSM 11.11 [14]. 

Command parameters/data: 



Description 


Section 


M/0 


Min 


Length 


Event download tag 


13.1 


M 


Y 


1 


Length (A+B+C+D+E) 


- 


M 


Y 


1 or 2 


Event list 


12.25 


M 


Y 


A 


Device identities 


12.7 


M 


Y 


B 


Transaction identifier 


12.28 


M 


Y 


C 


Address 


12.1 


M/0 


N 


D 


Called party subaddress 


12.3 


M/O 


N 


E 



M/O reflects that inclusion of the object is conditional, as defined in the text below. 

Event list: the event list object shall contain only one event (value part of length 1 byte), and ME shall set the event to: 
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MT call 

Device identities: the ME shall set the device identities to: 
Source: Network 

Destination: SIM 

Transaction identifier: the transaction identifier data object shall contain one transaction identifier, and this shall be the 
Transaction Identifier in the SETUP message from the network. 

Address: The address data object holds the Calling Line Identity as received by the ME in the SETUP message. If the 
Calling Line Identity is included in the SETUP message, the ME shall include the Address object, otherwise the ME 
shall not include the Address object. 

Called party subaddress: The called party subaddress data object holds the Calling Line Identity Subaddress as received 
by the ME in the SETUP message. If the Calling Line Identity Subaddress is included in the SETUP message, the ME 
shall include the Called party subaddress object, otherwise the ME shall not include the called party subaddress object. 

Response parameters/data: 
None. 

1 1 .2 Call connected event 

11.2.1 Procedure 

If the call connected event is part of the current event list (as set up by the last SET UP EVENT LIST command, see section 
6.4.16), then when the ME receives an incoming CONNECT message (in the case of an MO call), or when the ME sends an 
outgoing CONNECT message (in the case of an MT call), the ME shall inform the SIM that this has occurred, by using the 
ENVELOPE (EVENT DOWNLOAD - call connected) command as defined below. 

In the case of a call initiated through a SET UP CALL proactive command while the call connected event is part of the current 
event list, the ME shall send both the TERMINAL RESPONSE related to the proactive command, and the EVENT 
DOWNLOAD command, in the order TERMINAL RESPONSE first, ENVELOPE(EVENT DOWNLOAD - call connected) 
second. 

1 1 .2.2 Structure of ENVELOPE (EVENT DOWNLOAD - call connected) 

Direction: ME to SIM 

The command header is specified in GSM ILl 1 [14]. 

Command parameters/data: 



Description 


Section 


M/0 


Min 


Length 


Event download tag 


13.1 


M 


Y 


1 


Length (A+B+C) 


- 


M 


Y 


1 or 2 


Event list 


12.25 


M 


Y 


A 


Device identities 


12.7 


M 


Y 


B 


Transaction identifier 


12.28 


M 


Y 


C 



Event list: the event list object shall contain only one event (value part of length 1 byte), and ME shall set the event to: 
Call connected 

Device identities: 

In the case of connecting at the near end (an MT call), the ME shall set the device identities to: 

Source: ME 

Destination: SIM 

In the case of connecting at the far end (an MO call), the ME shall set the device identities to: 
Source: Network 

Destination: SIM 
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Transaction identifier: the transaction identifier data object shall contain one transaction identifier, and this shall be the 
Transaction Identifier in the CONNECT message. 

Response parameters/data: 
None. 

1 1 .3 Call disconnected event 

11.3.1 Procedure 

If the call disconnected event is part of the current event list (as set up by the last SET UP EVENT LIST command, see section 
6.4.16), then if the ME is not in the CC UO (NULL) state (i.e. has sent or received a SETUP message, see TS GSM 04.08 [8]), 
and in this state disconnects a call, the ME shall inform the SIM that this has occurred, by using the ENVELOPE (EVENT 
DOWNLOAD - call disconnected) command as defined below. This can happen as the result of the ME sending or receiving a 
DISCONNECT, RELEASE, or RELEASE COMPLETE message, or as the result of a radio link failure; if more than one of 
these occur within the same call, the ENVELOPE command shall be sent on the first occurrence. 

If the ME initiates the disconnection, or in the case of radio link failure, this is considered a "near end" disconnection, whereas 
a "far end" disconnection is defined as when the network initiates the disconnection. The ME shall set the Device Identities 
accordingly. 

1 1 .3.2 Structure of ENVELOPE (EVENT DOWNLOAD - Call disconnected) 

Direction: ME to SIM 

The command header is specified in GSM ILl 1 [14]. 

Command parameters/data: 



Description 


Section 


M/0 


Min 


Length 


Event download tag 


13.1 


M 


Y 


1 


Length (A+B+C+D) 


- 


M 


Y 


1 or 2 


Event list 


12.25 


M 


Y 


A 


Device identities 


12.7 


M 


Y 


B 


Transaction identifier 


12.28 


M 


Y 


C 


Cause 


12.26 





N 


D 



Event list: the event list object shall contain only one event (value part of length 1 byte), and ME shall set the event to: 
Call disconnected 

Device identities: 

In the case of "near end" disconnection, the ME shall set the device identities to: 

Source: ME 

Destination: SIM 

In the case of "far end" disconnection, the ME shall set the device identities to: 
Source: Network 

Destination: SIM 



Transaction identifier: the transaction identifier data object shall contain a list of the transaction identifiers for each of 
the calls being disconnected. 

Cause: the cause shall reflect the CC-Cause information element sent or received in the DISCONNECT, RELEASE or 
RELEASE COMPLETE message (see TS GSM 04.08 [8]) triggering the ENVELOPE command. If the Cause 
information element was not present in the message, or the Cause data object shall not be included. In the case of a radio 
link timeout, the Cause data object shall be included, with a value part of zero length. 

Response parameters/data: 
None. 



GSM 11.14 version 6.0.0 GSM Release 1997 



50 



TS 101 267 V6.0.0 (1998-04) 



1 1 .4 Location status event 

11.4.1 Procedure 

If the location status event is part of the current event Hst (as set up by the last SET UP EVENT LIST command, see section 
6.4.16), then when the ME enters the MM-IDLE state (see TS GSM 04.08 [8]) with the result that either the Location status or 
Location information has been changed or updated, the ME shall inform the SIM that this has occurred, by using the 
ENVELOPE (EVENT DOWNLOAD - location status) command as defined below 

1 1 .4.2 Structure of ENVELOPE (EVENT DOWNLOAD - Location status) 

Direction: ME to SIM 

The command header is specified in GSM 11.11 [14]. 

Command parameters/data: 



Description 


Section 


M/0 


Min 


Length 


Event download tag 


13.1 


M 


Y 


1 


Length (A+B+C+D) 


- 


M 


Y 


1 or 2 


Event list 


12.25 


M 


Y 


A 


Device identities 


12.7 


M 


Y 


B 


Location status 


12.27 


M 


Y 


C 


Location information 


12.19 


M/0 


N 


D 



M/O reflects that inclusion of the object is conditional, as defined in the text below. 

Event list: the event list object shall contain only one event (value part of length 1 byte), and ME shall set the event to: 
Location status 

Device identities: the ME shall set the device identities to: 
Source: ME 

Destination: SIM 

- Location status: This object shall contain the current service state of the MS. 

- Location information: This object shall only be included if the Location status object indicates Normal Service. This 
object shall contain the details of the network, location area and cell that have been selected. 

Response parameters/data: 
None. 

1 1 .5 User activity event 

11.5.1 Procedure 

If the user activity event is part of the current event list (as set up by the last SET UP EVENT LIST command, see section 
6.4.16), then the ME shall follow the procedure below: 

When the ME next detects some user activity (e.g. a key-press, removal of key-lock), the ME shall inform the SIM that 
this has occurred, by using the ENVELOPE (EVENT DOWNLOAD - user activity) command as defined below. 

As a result of sending this command to the SIM, the ME shall remove the user activity event from its current event list. 
This is in order for the ME to report this event only once after the event has been requested by the SIM. 

1 1 .5.2 Structure of ENVELOPE (EVENT DOWNLOAD - User activity) 



Direction: ME to SIM 

The command header is specified in GSM 11.11 [14]. 
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Command parameters/data: 



Description 


Section 


M/0 


Min 


Length 


Event download tag 


13.1 


M 


Y 


1 


Length (A+B) 


- 


M 


Y 


1 or 2 


Event list 


12.25 


M 


Y 


A 


Device identities 


12.7 


M 


Y 


B 



Event list: the event list object shall contain only one event (value part of length 1 byte), and ME shall set the event to: 
User activity 

Device identities: the ME shall set the device identities to: 
Source: ME 

Destination: SIM 

Response parameters/data: 
None. 

1 1 .6 Idle screen available event 

11.6.1 Procedure 

If the idle screen available event is part of the current event list (as set up by the last SET UP EVENT LIST command, see 
section 6.4.16), then the ME shall follow the procedure below: 

When the ME next enters a state where it would accept rather than reject a DISPLAY TEXT command of normal 
priority, the ME shall inform the SIM that this has occurred, by using the ENVELOPE (EVENT DOWNLOAD - idle 
screen available) command as defined below. 

As a result of sending this command to the SIM, the ME shall remove the idle screen available event from its current 
event list. This is in order for the ME to report this event only once after the event has been requested by the SIM. 

1 1 .6.2 Structure of ENVELOPE (EVENT DOWNLOAD - Idle screen available) 

Direction: ME to SIM 

The command header is specified in GSM ILl 1 [14]. 

Command parameters/data: 



Description 


Section 


M/0 


Min 


Length 


Event download tag 


13.1 


M 


Y 


1 


Length (A+B) 


- 


M 


Y 


1 or 2 


Event list 


12.25 


M 


Y 


A 


Device identities 


12.7 


M 


Y 


B 



Event list: the event list object shall contain only one event (value part of length 1 byte), and ME shall set the event to: 
Idle screen available 

Device identities: the ME shall set the device identities to: 
Source: Display 

Destination: SIM 



Response parameters/data: 
None. 
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1 2 SIMPLE-TLV data objects 



This clause specifies the coding of the SIMPLE-TLV data objects, which are contained in a BER-TLV data object. SIMPLE- 
TLV data objects may be transferred across the interface in either direction. A SIMPLE-TLV data object consists of a tag of 
length one byte, a length indicator, which gives the number of bytes in the value field, and a value part of variable length, 
whose contents, meaning and coding are given below. 

Tag codings are given in subclause 13.3 for all SIMPLE-TLV data objects. 

'00' and 'FF' are never used as tag values for SIMPLE-TLVs. This is in alignment with ISO/IEC 7816-6 [17]. Padding 
characters are not allowed. 

For some of the SIMPLE-TLV data objects described, the length field shall be coded on 1 or 2 bytes (Y value) according to 
annex D, depending on the value of byte 1 . 

All bits and bytes indicated as RFU within all SIMPLE-TLV data objects shall be respectively set to and '00' by the sending 
entity. 

The handling of reserved values and RFU bits or bytes within all SIMPLE-TLV data objects at the receiving entity is described 
in subclause 6.10. 



12.1 Address 



Byte(s) 


Description 


Length 


1 


Address tag 


1 


2to{Y-1)+2 


Length (X) 


Y 


{Y-1)+3 


TON and NPI 


1 


{Y-1)+4to 
(Y-1)+X+2 


Dialling number string 


X-1 



TON/NPI is coded as for EF^dn- 

Dialling number string is coded as for EF^j-jj,^, and may include DTMF separators and DTMF digits, which the ME shall send 
in the same way as for EF^qj,^. 

See GSM 1 1.1 1 [14] for the coding of all EFs. 



12.2 Alpha identifier 



Byte(s) 


Description 


Length 


1 


Alpha identifier tag 


1 


2to{Y-1)+2 


Length (X) 


Y1 


{Y-1)+3to 
(Y-1)+X+2 


Alpha identifier 


X 



The alpha identifier is coded as for EF^pj^. 
See GSM 11.11 [14] for the coding of all EFs. 



12.3 Called party subaddress 



Byte(s) 


Description 


Length 


1 


Called party subaddress tag 


1 


2to{Y-1)+2 


Length (X) 


Y 


(Y-1)+3to 
(Y-1)+X+2 


Called party subaddress 


X 
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Called party subaddress contains information as defined for this purpose in GSM 04.08 [8]. All information defined in 

GSM 04.08 shall be given in the value part of the data object, except the information element identifier and the length of called 

party subaddress contents (which is given by the length part of the data object). 

12.4 Capability configuration parameters 



Byte(s) 


Description 


Length 


1 


Capability configuration parameters tag 


1 


2to{Y-1)+2 


Length (X) 


Y 


{Y-1)+3to 
(Y-1)+X+2 


Capability configuration parameters 


X 



Capability configuration parameters are coded as for EF^^^p. If it is being provided by the SIM, the SIM shall supply all 
information required to complete the Bearer Capability Information Element in the Call Set-up message (see GSM 04.08 [8]). 
Any unused bytes at the end of the value part shall be coded 'FF'. 

See GSM 1 1.1 1 [14] for the coding of all EFs. 



12.5 Cell Broadcast Page 



Byte(s) 


Description 


Length 


1 


Cell Broadcast page tag 


1 


2 


Length = '58' (88 decimal) 


1 


3-90 


Cell Broadcast page 


88 



The Cell Broadcast page is formatted in the same way as described in GSM 03.41 [7]. 



12.6 Command details 



Byte(s) 


Description 


Length 


1 


Command details tag 




2 


Length = '03' 




3 


Command number 




4 


Type of command 




5 


Command Qualifier 





Command number 
For contents and coding, see subclause 6.5.1. 

Type of command: 
Contents: The Type of Command specifies the required interpretation of the data objects which follow, and the required ME 
procedure. 

Coding: 

See section 13.4 

The ME shall respond to reserved values (i.e. values not listed) with the result "Command type not understood". 

Command Qualifier: 
Contents: Qualifiers specific to the command. 

Coding: 

- REFRESH; 

'00' =SIM Initialization and Full File Change Notification; 

'01' = File Change Notification; 

'02' = SIM Initialization and File Change Notification; 

'03' = SIM InitiaHzation; 

'04' = SIM Reset; 
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'05' = SET UP EVENT LIST, if $(Event)$ is supported; 
'06' to 'FF' = reserved values. 

- MORE TIME; 

This byte is RFU. 

- POLL INTERVAL; 

This byte is RFU. 

- POLLING OFF; 

This byte is RFU. 

- SET UP CALL; 

'00' = set up call, but only if not currently busy on another call; 

'Or = set up call, but only if not currently busy on another call, with redial; 

'02' = set up call, putting all other calls (if any) on hold; 

'03' = set up call, putting all other calls (if any) on hold, with redial; 

'04' = set up call, disconnecting all other calls (if any); 

'05' = set up call, disconnecting all other calls (if any), with redial; 

'06' to 'FF' = reserved values. 

- SET UP EVENT LIST; 

This byte is RFU, if $(Event)$ is supported. 

- SEND SS; 

This byte is RFU. 

- SEND USSD; 

This byte is RFU. 

- SEND SHORT MESSAGE; 

bit 1 : = packing not required 

1 = SMS packing by the ME required 
bits 2-8: =0 RFU. 

- PLAY TONE; 

This byte is RFU. 

- DISPLAY TEXT, 

bit 1 : = normal priority 

1 = high priority 

bits 2-7: = RFU 

bit 8: = clear message after a delay 

1 = wait for user to clear message 

- GET INKEY, 

bit 1 = digits (0-9, *, # and +) only 

1 = alphabet set; 
bit 2 = SMS default alphabet 

1 = UCS2 alphabet if $(UCS2)$ is supportedbits 3-7: = RFU 
bit 8: = no help information available and if $(HelpInfo)$ is supported 

1 = help information available and if $(HelpInfo)$ is supported 

RFU if $(HelpInfo)$ not supported 

- GET INPUT, 

bit 1 = digits (0-9, *, #, and +) only 

1 = alphabet set 
bit 2 = SMS default alphabet 

1 = UCS2 alphabet if $(UCS2)$ is supported 
bit 3: = ME may echo user input on the display 

1 = user input shall not be revealed in any way (see note) 
bit 4: = user input to be in unpacked format 

1 = user input to be in SMS packed format 
bits 5 to 7: = RFU 
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bit 8: = no help information available and if $(HelpInfo)$ is supported 

1 = help information available and if $(HelpInfo)$ is supported 
RFU if $(HelpInfo)$ is not supported 

NOTE: Where user input is not to be revealed, the ME may provide an indication of key entries, such as by displaying 
"*"s. See subclause 6.4.3 for more information on the character set available in this mode. 

- SELECT ITEM. 

bits 1 to 7: = RFU 

bit 8: = no help information available and if $(HelpInfo)$ is supported 

1 = help information available and if $(HelpInfo)$ is supported 

RFU if $(HelpInfo)$ is not supported 

- SET UP MENU. 

bits 1 to 7 = RFU 

bit 8 = no help information available and if $(HelpInfo)$ is supported 

1 = help information available and if $(HelpInfo)$ is supported 

RFU if $(HelpInfo)$ is not supported 

PROVIDE LOCAL INFORMATION 

'00' = Location Information (MCC, MNC, LAC and Cell Identity) 
'01' = IMEIoftheME 

'02' = Network Measurement results, if $(NMR)$ is supported 
'03' to 'FF' = Reserved 

The ME shall respond to reserved values with the result "Command type not understood". 



12.7 Device identities 



Byte(s) 


Description 


Length 


1 


Device identities tag 


1 


2 


Length = '02' 


1 


3 


Source device identity 


1 


4 


Destination device identity 


1 



Source device identity 
Contents: the source device for information held in the data objects which follow. 

Destination device identity 
Contents: the destination device for information held in the data objects which follow. 

NOTE: Only some combinations of Type of Command, Data Download type and Device identities are allowed. These 
are defined in clause 14. 



Coding: both Source and Destination device identities are coded as follows: 
'01' = Keypad 
'02' = Display 
'03' = Earpiece 

- '81' = SIM 

- '82' = ME 

- '83' = Network 

All other values are reserved. 
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12.8 Duration 



Byte(s) 


Description 


Length 


1 


Duration tag 


1 


2 


Length = '02' 


1 


3 


Time unit 


1 


4 


Time interval 


1 



Time unit 
Contents: time unit used; minutes, seconds or tenths of seconds. 

Coding: 

'00' Minutes 

'Or Seconds 

'02' Tenths of seconds 

All other values are reserved. 

Time interval 
Contents: the length of time required, expressed in units. 

Coding: The time interval is coded in integer multiples of the time unit used. The range is from 1 unit to 255 units. The 
encoding is: 

'00': reserved 
- '01': 1 unit 
'02': 2 units 

'FF': 255 units 



12.9 Item 



Byte(s) 


Description 


Length 


1 


Item tag 


1 


2to{Y-1)+2 


Length (X) 


Y 


{Y-1)+3 


Identifier of item 


1 


{Y-1)+4to 
(Y-1)+X+2 


Text string of item 


X-1 



The identifier is a single byte between '01' and 'FF'. Each item shall have a unique identifier within an Item list. 

The text string is coded in the same way as the alpha identifier for EF^^j,^. Any unused bytes at the end of the value part shall 
be coded 'FF'. 

12.10 Item identifier 



Byte(s) 


Description 


Length 


1 


Item identifier tag 


1 


2 


Length = '01' 


1 


3 


Identifier of item chosen 


1 



The identifier is a single byte between '01' and 'FF', exactly the same as for the Item data object. A null item identifier is coded 
'00'. 
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12.11 Response length 



Byte(s) 


Description 


Length 


1 


Response length tag 


1 


2 


Length = '02' 


1 


3 


Minimum length of response 


1 


4 


IVIaximum length of response 


1 



The range of length is between '00' and 'FF'. A minimum length coding of '00' indicates that there is no minimum length 
requirement; a maximum length coding of 'FF' indicates that there is no maximum length requirement. If a fixed length is 
required the minimum and maximum values are identical. 

12.12 Result 



Byte(s) 


Description 


Length 


1 


Result tag 


1 


2to{Y-1)+2 


Length (X) 


Y 


{Y-1)+3 


General result 


1 


{Y-1)+4to 
(Y-1)+X+2 


Additional information on result 


X-1 



General result 
Contents: General result specifies the result and indicates appropriate SIM action: 

Coding: 

'00' = Command performed successfully; 

'01' = Command performed with partial comprehension; 

'02' = Command performed, with missing information; 

'03' = REFRESH performed with additional EFs read; 

'10' = Proactive SIM session terminated by the user; 

'11' = Backward move in the proactive SIM session requested by the user; 

'12' = No response from user; 

'13' = Help information required by the user, if $(HelpInfo)$ is supported. 

Results 'OX' and 'IX' indicate that the command has been performed. 
'20' = ME currently unable to process command; 
'21' = Network currently unable to process command; 
'22' = User did not accept call set-up request; 
'23' = User cleared down call before connection or network release; 

Results '2X' indicate to the SIM that it may be worth re-trying the command at a later opportunity. 
'30' = Command beyond ME's capabilities; 
'31' = Command type not understood by ME; 
'32' = Command data not understood by ME; 
'33' = Command number not known by ME; 

- '34' = SS Return Error; 

- '35' = SMS RP-ERROR; 

'36' = Error, required values are missing. 

- '37' = USSD Return Error, if $(SendUSSD)$ is supported 

Results '3X' indicate that it is not worth the SIM re-trying with an identical command, as it will only get the same response. 
However, the decision to retry lies with the SIM application. 

The SIM application should avoid a rapid sequence of repeated retried commands as this may be detrimental to ME 
performance. 

All other values are reserved. 



Additional information 
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Contents: For the general result "Command performed successfully", some proactive commands require additional 

information in the command result. This is defined in the subclauses below. For the general results '20', '21', '34' and '35', 
it is mandatory for the ME to provide a specific cause value as additional information, as defined in the subclauses 
below. For the other general results, the ME may optionally supply additional information. If additional information is 
not supplied, then the length of the value part of the data object need only contain the general result. 

1 2.1 2.1 Additional information for SEND SS 

When the ME issues a successful COMMAND RESULT for a SEND SS proactive command, it shall also include the 
Operation Code and Parameters included in the Return Result component from the network, as additional information. 

The first byte of the additional information shall be the SS Return Result Operation code, as defined in GSM 04. 11 [9]. 

The rest of the additional information shall be the SS Return Result Parameters, as defined in GSM 04.11 [9]. 

1 2.1 2.2 Additional information for ME problem 

For the general result "ME currently unable to process command", it is mandatory for the ME to provide additional 
information, the first byte of which to be as defined below: 

'00' = No specific cause can be given; 

'01' = Screen is busy; 

'02' = ME currently busy on call; 

'03' = ME currently busy on SS transaction; 

'04' = No service; 

'05' = Access control class bar; 

'06' = Radio resource not granted; 

'07' = Not in speech call. 

'08' = ME currently busy on USSD transaction 

All other values shall be interpreted by the SIM as '00'. The coding '00' shall only be used by the ME if no others apply. 

1 2.1 2.3 Additional information for network problem 

For the general result "network currently unable to process command", it is mandatory for the ME to provide additional 
information. The first byte shall be the cause value of the Cause information element returned by the network (as defined in 
GSM 04.08 [8]). Bit 8 shall be set to '1'. One further value is defined: 

'00' = No specific cause can be given. 

All other values shall be interpreted by the SIM as '00'. The coding '00' shall only be used by the ME if no others apply. 

1 2.1 2.4 Additional information for SS problem 

For the general result "SS Return Error", it is mandatory for the ME to provide additional information. The first byte shall be 
the error value given in the Facility (Return result) information element returned by the network (as defined in 
GSM 04.80 [10]). One further value is defined: 

'00' = No specific cause can be given. 

All other values shall be interpreted by the SIM as '00'. The coding '00' shall only be used by the ME if no others apply. 

1 2.1 2.5 Additional information for SMS problem 

For the general result "SMS RP-ERROR", it is mandatory for the ME to provide additional information. The first byte shall be 
the cause value given in the RP-Cause element of the RP-ERROR message returned by the network (as defined in 
GSM 04.1 1 [9]), with bit 8 = 0. One further value is defined: 

'00' = No specific cause can be given. 

All other values shall be interpreted by the SIM as '00'. Specific cause '00' shall only be used by the ME if no others apply. 
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12.12.6 Additional information for SELECT ITEM 

If $(HelpInfo)$ is supported, then for the general result "Help information required by the user", the ME shall provide 
additional information. The ME shall supply the identifier of the item for which the user is requiring help information using the 
item identifier data object as defined in subclause 12.10. 

12.12.7 Additional information for USSD problem 

This subclause applies if $(SendUSSD)$ is supported 

For the general result "USSD Return Error", the ME shall provide additional information. The first byte shall be the error value 
given in the Facility (Return result) information element returned by the network (as defined in GSM 04.80 [10]). One further 
value is defined: 

'00' = No specific cause can be given. 

All other values shall be interpreted by the SIM as '00'. 

The coding '00' shall only be used by the ME if no others apply. 

12.13 SMSTPDU 



Byte(s) 


Description 


Length 


1 


SMS TPDU tag 


1 


2to(Y-1)+2 


Length (X) 


Y 


(Y-1)+3to 
(Y-1 )+X+2 


SMSTPDU 


X 



The TPDU is formatted as described in GSM 03.40 [6]. 

Where the TPDU is being sent from the SIM to the ME (to be forwarded to the network), and where it includes a TP-Message- 
Reference which is to be incremented by the ME for every outgoing message, the TP-Message-Reference as provided by the 
SIM need not be the valid value. TP-Message-Reference shall be checked and corrected by the ME to the value described in 
GSM 03.40 [6]. 



12.14 SS string 



Byte(s) 


Description 


Length 


1 


SS string tag 


1 


2to(Y-1)+2 


Length (X) 


Y 


(Y-1)+3 


TON and NPI 


1 


(Y-1)+4to 
(Y-1)+X+2 


SS or USSD string 


X-1 



TON/NPI and SS or USSD control string are coded as for EF^qj,^, where the ADN record relates to a Supplementary Service 
Control string. See GSM 11.11 [14] for the coding of EF^qj^. 



12.15 Text string 



Byte(s) 


Description 


Length 


1 


Text string tag 


1 


2to(Y-1)+2 


Length (X) 


Y 


(Y-1)+3 


Data coding scheme 


1 


(Y-1)+4to 
(Y-1)+X+2 


Text string 


X-1 



A null text string shall be coded with Length = '00', and no Value part. 
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Data coding scheme is coded as for SMS Data coding scheme defined in GSM 03.38 [5]. 

1 2.1 5.1 Coding of text in unpadded format 

This is indicated by the data coding scheme having a value of 8 bit data. Other parts of the data coding scheme shall be ignored. 

This string shall be no longer than 160 characters, and use the SMS default 7-bit coded alphabet as defined in GSM 03.38 [5] 
with bit 8 set to 0. It may or may not include formatting characters, but all such formatting characters shall be taken from the set 
given in the SMS alphabet. 

NOTE: This is exactly the same format as is used for EF^qj,^ alpha-identifiers. It is also the same as SMS messages that 
have been "unpacked". 

1 2.1 5.2 Coding of text in pacl^ed format 

This is indicated by the data coding scheme having a value of 7 bit GSM default alphabet. Other parts of the data coding 
scheme shall be ignored. 

This string shall be no longer than 160 characters, and use the SMS default 7-bit coded alphabet, packed into 8-bit octets, as 
defined in GSM 03.38 [5]. It may or may not include formatting characters, but all such formatting characters shall be taken 
from the set given in the SMS alphabet. 

If the total number of characters in the text string equals (8n-l) where n=l,2,3 etc. then there are 7 spare bits at the end of the 
message. To avoid the situation where the receiving entity confuses 7 binary zero pad bits as the @ character, the carriage 
return (i.e. <CR>) character shall be used for padding in this situation, as defined in GSM 03.38 [5]. 

NOTE: This is the same format as is used in SMS messages to and from the network. 

1 2.1 5.3 Coding of text in 1 6 bits UCS2 alpinabet format 

This subclause applies only if $(UCS2)$ is supported. 

This is indicated by the data coding scheme having a value of 16 bit UCS2 alphabet. Other parts of the data coding scheme 
shall be ignored. 

This string shall be no longer than 140 bytes, i.e. up to 70 UCS2 characters and use the UCS2 alphabet if the $(UCS2)$ is 
supported, as defined in GSM 03.38 [5]. It may or may not include formatting characters, but all such formatting characters 
shall be taken from the set given in the UCS2 alphabet. 

NOTE: This is the same format as is used in SMS messages to and from the network. 

12.16 Tone 



Byte(s) 


Description 


Length 


1 


Tone tag 


1 


2 


Length = '01' 


1 


3 


Tone 


1 



- Tone 

Contents: Tones can be either the standard supervisory tone, as defined in GSM 02.40 [18], or proprietary tones defined by 
the ME manufacturer. The code values for proprietary tones shall be supported by the ME. If proprietary tones are not 
supported the ME shall map these codings to tones that it can generate. The tones to be used are left as an 
implementation decision by the manufacturer. 
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Coding: 

Standard supervisory tones: 

'Or Dial tone 

'02' Called subscriber busy 

'03' Congestion 

'04' Radio path acknowledge 

'05' Radio path not available / Call dropped 

'06' Error / Special information 

'07' Call waiting tone 

'08' Ringing tone 

ME proprietary tones: 

'10' General beep 

' ir Positive acknowledgement tone 

'12' Negative acknowledgement or error tone 

All other values are reserved. 



12.17 USSD string 

This subclause applies if $(SendUSSD)$ is supported 



Byte(s) 


Description 


Length 


1 


USSD string tag 


1 


2 


Length (X) 


1 


3-X+2 


USSD string 


X 



The coding of the USSD string is defined in GSM 02.30 [4]. 



12.18 File List 



Byte(s) 


Description 


Length 


1 


File List tag 


1 


2to{Y-1)+2 


Length (X) of bytes following 


Y 


{Y-1)+3 


Number of files (n) 


1 


{Y-1)+4to 
(Y-1)+X+2 


Files 


X-1 



Number of files: 

This is the number of files that will be described in the following list. 

Files: 

Full paths are given to files. Each of these shall be at least 4 octets in length (e.g. '3F002FE2' or '3F007F206FAD'). Each entry 

in the file description is composed of two bytes, where the first byte identifies the type of file (see GSM 11.11). 

An entry in the file description shall therefore always begin with '3FXX'. There can be any number of Dedicated File entries 
between the Master File and Elementary File. There shall be no delimiters between files, as this is implied by the fact that the 
full path to any EF starts with '3FXX' and ends with an Elementary type file. 
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12.19 LOCATION INFORMATION 



Byte(s) 


Description 


Length 


1 


Location Information tag 


1 


2 


Length = '07' 


1 


3-5 


Mobile Country & Network Codes (IVICC & IVINC) 


3 


6-7 


Location Area Code (LAC) 


2 


8-9 


Cell Identity Value (Cell ID) 


2 



The mobile country code (MCC), the mobile network code (MNC), the location area code (LAC) and the cell ID are coded as 
in GSM 04.08 [8]. 

12.20 IMEI 



Byte(s) 


Description 


Length 


1 


IMEI tag 


1 


2 


Length = '08' 


1 


3-10 


IMEI of the ME 


8 



The IMEI is coded as in GSM 04.08 [8]. 



12.21 Help Request 

This subclause applies only if $(HelpInfo)$ is supported. 



Byte(s) 


Description 


Length 


1 


Help Request tag 


1 


2 


Length = '00' 


1 



12.22 Network Measurement Results 

This subclause applies only if $(NMR)$ is supported. 



Byte(s) 


Description 


Length 


1 


Network Measurement Results tag 


1 


2 


Length = '10' 


1 


3-18 


Network Measurement Results 


16 



The Network Measurement Results are coded as for the Measurement Results information element in GSM 04.08 [8], starting 
at octet 2 (the lEI is removed, as this information is duplicated by the data object tag). 



12.23 Default Text 

This subclause applies only if $(DefChoice)$ is supported. 

The coding of this data object is the same as for the Text String data object (see subclause 12. 15) with the exception that the 
Default Text tag has a specific value (see subclause 13.3). 
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12.24 Items Next Action Indicator 

The subclause applies only if $(NextAction)$ is supported. 



Byte(s) 


Description 


Length 


1 


Items Next Action Indicator tag 


1 


2 


Length (X) 


1 


3 to 3+X-1 


Items Next Action Indicator list 


X 



Contents : Each item of a list of items has a next action indicator coded on one byte. The length of the 

Items Next Action Indicator list shall be the number of items of the list of items (X shall be the number of items in the list). The 
order of each item next action indicator, shall reflect the order o the items in the list of items. 

The Item Next action indicator gives the possible actions that will be initiated by the SIM in case of selection by the user. 

Coding : If the value is equal to '00' or if the value is reserved (that is, value not listed), the ME shall ignore the next action 
indicator type. 

See subclause 13.4 for further information. 

Example : 

For the following list of items : 
-item#l; 

- item #2; 

- item #3; 

- item #n, 

the Items Next Action Indicator (NAI) shall be as follows : 



Tag 


Length 


NAI#I 


NAI#2 


NAI#3 




NAI#n 



12.25 Event list 

This subclause applies only if $(Event)$ is supported. 



Byte(s) 


Description 


Length 


1 


Event list tag 


1 


2 to Y+1 


Length (X) of bytes following 


Y 


Y+2to 
X+Y+1 


Event list 


X 



Event list 
Contents: A list of events, of variable length. Each byte in the list defines an event. Each event type shall not appear more 
than once within the list. 

Coding: Each byte in the event list shall be coded with one of the values below: 
- '00' = MT call 

'01' = Call connected 

'02' = Call disconnected 

'03' = Location status 

'04' = User activity 

'05' = Idle screen available 
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12.26 Cause 

This subclause applies only if $(Event)$ is supported. 



Byte(s) 


Description 


Length! 


1 


Cause tag 


1 


2 


Length (X) of bytes following. X=0, or 2 < X < 30. 


1 


3 to X+2 


Cause 


X 



The Cause data object is coded as for the Cause call control information element in GSM 04.08 [8], starting at octet 3 (the lEI 
and Length information are removed, as this information is duplicated by the data object tag and length). 

Radio Link Timeout is indicated by the Cause data object having a value part of zero length (only the Tag and Length 
components are sent). 



12.27 Location status 

This subclause applies only if $(Event)$ is supported. 



Byte(s) 


Description 


Length 


1 


Location status tag 


1 


2 


Length (X) of bytes following 


1 


3 


Location status 


1 



Location status 

Contents: this data object indicates the current service state of the MS. 

"Normal service" shall indicate that the MS is in a state where all requests for services are treated normally. 

"Limited service" shall indicate that the MS is in a state where only emergency call services are offered. 

"No service" shall indicate that the MS is in a state where no services are offered. 

Coding: Each byte in the event list shall be coded with one of the values below: 
'00' = Normal service 
'01 ' = Limited service 
'02' = No service 



12.28 Transaction identifier 

This subclause applies only if $(Event)$ is supported. 



Byte(s) 


Description 


Lengtii 


1 


Location status tag 


1 


2 


Length (X) of bytes following 


1 


3 to X+2 


Transaction identifier list 


X 



Transaction identifier list 

Contents: A list of transaction identifiers, of variable length. Each byte in the list defines a transaction identifier. Each 
transaction identifier shall not appear more than once within the list. 

Coding: Each byte in the transaction identifier list shall be coded as defined below: 
bits 1 to 4 = RFU 
bits 5 to 7 = TI value 
bit 8 = TI flag 

TI value and TI flag are coded as defined in GSM 04.07 [23]. 
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13 Tag values 

This clause specifies the tag values used to identify the BER-TLV and SIMPLE-TLV data objects used in this specification. 

13.1 BER-TLV tags in ME to SIM direction 



Description 


Length of tag 


Value 


SMS-PP download tag 




'D1' 


Cell Broadcast download tag 




'D2' 


Menu Selection tag 




'D3' 


Call control tag 




'D4' 


MO Short message control tag (if $(MOSMcontrol is 
supported) 




'D5' 


Event download tag, if $(Event)$ is supported 


1 


'D6' 



1 3.2 BER-TLV tags in SIM TO ME direction 



Description 


Length of tag 


Value 


Proactive SIM command tag 


1 


'DO' 



1 3.3 SIMPLE-TLV tags in both directions 



8 


7 


6 


5 1 4 1 3 


2 


1 1 


CR 


Tag value 



CR: Comprehension required for this object. 

Unless otherwise stated, for SIMPLE-TLV data objects it is the responsibility of the SIM application and the ME to decide the 
value of the CR flag for each data object in a given command. 

Handling of the CR flag at the receiving entity is described in subclause 6.10. 



CR 


Value 


Comprehension required 


1 


Comprehension not required 
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Description 


Length of tag 


Tag value, bits 1-7 
(Range: -or -'7E') 


Tag 
(CR and Tag value) 


Command details tag 




'01' 


'01 'or '81' 


Device identity tag 




'02' 


'02' or '82' 


Result tag 




'03' 


'03' or '83' 


Duration tag 




'04' 


'04' or '84' 


Alpha identifier tag 




'05' 


'05' or '85' 


Address tag 




'06' 


'06' or '86' 


Capability configuration parameters tag 




'07' 


'07' or '87' 


Called party subaddress tag 




'08' 


'08' or '88' 


SS string tag 




'09' 


'09' or '89' 


USSD string tag, if $(SendUSSD)$ is 
supported 




'OA' 


'OA' or '8A' 


SMS TPDU tag 




'OB' 


'OB' or '8B' 


Cell Broadcast page tag 




'OC 


'OC or '8C' 


Text string tag 




'OD' 


'OD' or '8D' 


Tone tag 




'OE' 


'OE' or '8E' 


Item tag 




'OF' 


'OF' or '8F' 


Item identifier tag 




'10' 


'10' or '90' 


Response length tag 




'11' 


'11 'or '91' 


File List tag 




'12' 


'12' or '92' 


Location Information tag 




'13' 


'13' or '93' 


IMEI tag 




'14' 


'14' or '94' 


Help request tag (only if ${Helplnfo)$ is 
supported 




'15' 


'15' or '95' 


Network Measurement Results tag if 
$(NMR)$ is supported 




'16' 


'16' or '96' 


Default Text (only if $(DefChoice)$ is 
supported) 




'17' 


'17' or '97' 


Items Next Action Indicator tag (only if 
$(NextAction)$ is supported) 




'18' 


'18' only 


Event list tag (only if $(Event)$ is 
supported) 




'19' 


'19' or '99' 


Cause tag (only if $(Event)$ is 
supported) 




'1A' 


'1A'or'9A' 


Location status tag (only if $(Event)$ is 
supported) 




'IB' 


'1B'or'9B' 


Transaction identifier tag (only if 
$(Event)$ is supported) 




'IC 


'1C'or'9C' 



13.4 Type of Command and Next Action Indicator 

The table below shows the values which shall be used for Type of Command coding (see subclause 12.6) and Next Action 
Indicator coding (see subclause 12.24). 
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Value 


Name 


used for Type of Command 
coding 


used for Next Action 

Indicator coding (if 

$(NextAction)$ is supported) 


'00' 




- 


- 


'01' 


REFRESH 


X 




'02' 


MORE TIME 


X 




'03' 


POLL INTERVAL 


X 




'04' 


POLLING OFF 


X 




'10' 


SET UP CALL 


X 


X 


'11' 


SENDSS 


X 


X 


'12' 


SEND USSD 


X 


X 


'13' 


SEND SHORT MESSAGE 


X 


X 


'20' 


PLAY TONE 


X 


X 


'21' 


DISPLAY TEXT 


X 


X 


'22' 


GET INKEY 


X 


X 


'23' 


GET INPUT 


X 


X 


'24' 


SELECT ITEM 


X 


X 


'25' 


SET UP MENU 


X 


X 


'26' 


PROVIDE LOCAL INFORMATION 


X 




'81' 


End of the proactive session 


not applicable 


X 



14 Allowed Type of command and Device identity 
combinations 

Only certain types of commands can be issued with certain device identities. These are defined below: 



Command description 


Source 


Destination 


CALL CONTROL 


ME 


SIM 


CELL BROADCAST DOWNLOAD 


Network 


SIM 


COMMAND RESULT 


ME 


SIM 


DISPLAY TEXT 


SIM 


Display 


EVENT DOWNLOAD (if $(Event)$ is supported) 






- MT call 


Network 


SIM 


- Call connected at near end (MT call) 


ME 


SIM 


- Call connected at far end (MO call) 


Network 


SIM 


- Call disconnected at near end 


ME 


SIM 


- Call disconnected at far end 


Network 


SIM 


- Location status 


ME 


SIM 


- User activity 


ME 


SIM 


- Idle screen available 


Display 


SIM 


GET INKEY 


SIM 


ME 


GET INPUT 


SIM 


ME 


MENU SELECTION 


Keypad 


SIM 


MO SHORT MESSAGE CONTROL 


ME 


SIM 


MORE TIME 


SIM 


ME 


PLAY TONE 


SIM 


Earpiece (see note) 


POLLING OFF 


SIM 


ME 


POLL INTERVAL 


SIM 


ME 


PROFILE DOWNLOAD 


ME 


SIM 


REFRESH 


SIM 


ME 


SELECT ITEM 


SIM 


ME 


SEND SHORT MESSAGE 


SIM 


Network 


SENDSS 


SIM 


Network 


SEND USSD 


SIM 


Network 


SET UP CALL 


SIM 


Network 


SET UP EVENT LIST 


SIM 


ME 


SET UP MENU 


SIM 


ME 


SMS-PP DOWNLOAD 


Network 


SIM 


PROVIDE LOCAL INFORMATION 


SIM 


ME 



NOTE: The ME may route the tone to other loudspeakers (external ringer, car kit) if more appropriate. 
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15 Security requirements 

To be defined. 

NOTE: This will be elaborated in joint meetings between ETSI/STC/SMG9 and ETSI/STC/SMGIO. At the present time, 
there are no standardised requirements concerning security. 
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Annex A (normative): 

Mandatory support of SIM Application Toolkit by Mobile 

Equipment 

Support of SIM Application Toolkit is optional for Mobile Equipment. However, any ME claiming to support SIM Application 
Toolkit need not support all toolkit functions, but shall support all functions within a class as given in the table below. Class 3 
is still under discussion, and further features may be added. 







Classes 


Command description 




1 


2 


3 


CALL CONTROL 






X 


X 


CELL BROADCAST DOWNLOAD 






X 


X 


DISPLAY TEXT 






X 


X 


EVENT DOWNLOAD, if ${Event)$ is supported 










- MT call 








X 


- Call connected 








X 


- Call disconnected 








X 


- Location status 








X 


- User activity 








X 


- Idle screen available 








X 


GET INKEY 






X 


X 


GET INPUT 






X 


X 


MENU SELECTION 






X 


X 


MO SHORT MESSAGE CONTROL 








X 


MORE TIME 






X 


X 


PLAY TONE 






X 


X 


POLLING OFF 






X 


X 


POLL INTERVAL 






X 


X 


REFRESH 




X 


X 


X 


SELECT ITEM 






X 


X 


SEND SHORT MESSAGE 






X 


X 


SENDSS 






X 


X 


SEND USSD 








X 


SET UP CALL 






X 


X 


SET UP EVENT LIST, if $(Event)$ is supported 








X 


SET UP MENU 






X 


X 


SMS-PP DOWNLOAD 




X 


X 


X 


PROVIDE LOCAL INFORMATION 






X 


X 
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Annex B (informative): 

Example command sequences for proactive SIIVI 

This subclause shows example APDU sequences for proactive SIM commands, and is for information only. 

Case 1: Proactive SIM request following a normal command from the ME 

ME SIM 

I Normal command I 



Normal Data, if any |'91'|lgth| 



[Possible "normal GSM operation" command/response pairs] 



FETCH 



Proactive SIM command '90' '00' 



[Possible "normal GSM operation" command/response pairs] 
[ME performs command] 

TERMINAL RESPONSE (OK) I 



Case 2: Proactive SIM request following a (polling) STATUS command from the ME 

ME SIM 

I STATUS command I 



Normal Data on DF |'91'|lgth| 



[Possible "normal GSM operation" command/response pairs] 



FETCH 



Proactive SIM command '90 



[Possible "normal GSM operation" command/response pairs] 
[ME performs command] 

TERMINAL RESPONSE (OK) I 



'90' '0( 
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Case 3: STATUS command from ME, not followed by any proactive SIM request 

ME SIM 

I STATUS command I 

I Normal Data on DF I '90' I '00' I 



Case 4: Unsuccessful proactive SIM request, followed by SIM asking the ME to retry 

ME SIM 



Normal commiand 



Normal Data, if any |'91'|lgth| 



[Possible "normal GSM operation" command/response pairs] 

FETCH I 

I Proactive SIM command I '90' I '00' 

[Possible "normal GSM operation" command/response pairs] 
[ME performs command] 

TERMINAL RESPONSE (temporary problem) I 

I ' 91' llgthl 



[Possible "normal GSM operation" command/response pairs] 



FETCH 



Repeat of proactive SIM command I '90' 



[Possible "normal GSM operation" command/response pairs] 
[ME performs command] 

TERMINAL RESPONSE (OK) I 



Case 5: Unsuccessful proactive SIM request, and the SIM does not ask for the ME to retry 

ME SIM 

I Normal command I 



Normal Data, if any I '91 'llgthl 
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[Possible "normal GSM operation" command/response pairs] 
I FETCH I 

I Proactive SIM command I '90' I '00' I 

[Possible "normal GSM operation" command/response pairs] 
[ME performs command] 



TERMINAL RESPONSE (temporary problem) | 
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Annex C (informative): 

Example of DISPLAY TEXT Proactive SIIVI Command 

Example of DISPLAY TEXT Proactive SIM Command 
(BER-TLV Data Object) 



Byte# 


Value (Hex) 


Description 


1 


DO 


Proactive SIM command tag 


2 


OF 


length 


3 


81 


command details tag 


4 


03 


length 


5 


01 


command number 


6-7 


21 00 


Display text (normal priority, clear message after a 
delay) 


8 


82 


Device identities tag 


9 


02 


length 


10 


81 


source: SIM 


11 


02 


destination: Display 


12 


8D 


Text string tag 


13 


04 


length 


14 


04 


Data coding scheme ('04'=8-bit default SMS) 


15- 17 


53,41,54 


text string ("SAT") 
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Annex D (normative): 

Structure of SIM Application Toolkit communications 

BER-TLV data 
object 

SIMPLE-TLV 

data object 

Elements within 
the data object 

SIM Application Toolkit commands and responses are sent across the interface as BER-TLV data objects. Each APDU shall 
only contain one BER-TLV object. 



T 


L 


V 




l..n SIMPLE-TLV objects 




























T 


L 


V 


L.m elements 




T 


L 


V 



























The tag is a constant value, length one byte, indicating it is a SIM Application Toolkit command. 

The length is coded onto l,or 2 bytes according to ISO/lEC 7816-6 [17]. The following table details this coding: 



Length 


Bytel 


Byte 2 


0-127 


length ('00' to '7F') 


not present 


128-255 


'81' 


length ('80' to 'FF') 



Any length within the APDU limits (up to 255 bytes) can thus be encoded on two bytes. This coding is chosen to remain 
compatible with ISO/lEC 7816-6 [17]. 

Any values for byte 1 or byte 2 that are not shown above shall be treated as an error and the whole message shall be rejected. 

The value part of the BER-TLV data object consists of SIMPLE-TLV data objects, as shown in the description of the SIMPLE- 
TLV data objects on individual commands. It is mandatory for SIMPLE-TLV data objects to be provided in the order given in 
the description of each command. New SIMPLE-TLV data objects can be added to the end of a command. 

The M/O columns specify whether it is mandatory or optional for the sender to send that particular SIMPLE-TLV data object 
for compliance with the current version of this TS. The Min (Minimum Set) column describes whether it is necessary for the 
receiver to have received that particular SIMPLE-TLV data object to be able to attempt at least the most basic form of this 
command. The procedure for dealing with incomplete messages is described in subclause 6.10. 

'00' and 'FF' are never used as tag values for BER-TLVs. This is in accordance with ISO/lEC 7816-6 [17]. Padding characters 
are not allowed. 

See ISO/IEC 7816-6 [17] for more information on data objects. 
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Annex E (informative): 

IVIE display in proactive SIIVI session 

Example of the ME display whilst the ME is in a proactive SIM session. 
ME display ME 

[Setup menu being navigated] 



Setup 
Menu list 



Select 
Item list 



Get 
In key 



ME 
Display 



Envelope (Menu Selection) 



SW = 91 XX 



Fetch 



Select Item 



Terminal Response 



SW = 91 XX 



Fetch 



Get Inkey 



Terminal Response 



SW = 90 00 



SIM 
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Annex F (informative): 

Help information feature processing 



The following example shows the use of the commands Menu Selection / Select Item and Get Input in conjunction with the 
help information feature $(HelpInfo)$. 



ME 

TFRMIMAI PRDFII F 




--> 


SIM 

91 XX 




<- 


ppxpu 




--> 


qpT 1 IP N/IFMI 1 CHpIn a\/ailahlp\ 




<- 






TFRMIMAI RFCIPDMCIF inK\ 




--> 


Qfl nn 




<- 






FMVFI OPF CN/IFMI 1 C;p| FPTIDM 




--> 


91 XX 


help on menu item m) 


<- 


PPTPI-I 




--> 


nic:PI AY TFYT CHpJn infn tn itpm m^ 




<- 






TFRN/IIMAI RFQPnMCip inK^ 




-> 


qn nn 


(ME offers menu again and user 
selects item m) 

FMVFI OPF CMFMI 1 ciFI FPTIOM 


<- 


--> 
--> 


91 XX 

qpi PPT ITFM 


select item m) 

PPTPH 


<- 




<- 




(Item list under item m, help available) 


TFRMIMAI RFCIPOMCIF 




--> 


91 XX 


(Help on item mn in item list under 
item m ) 


<- 


PPTPI-I 




--> 


DISPLAY TEXT (Help info to item mn) 










TFRN/IIMAI RFQPDMCIF inK^ 




-> 


91 XX 




<- 


PPTPH 




--> 


Ronptitinn nf C;p| pPT ITFN/I 


PPTPH 


<- 
<- 


--> 


(Item list under item m, help available) 
91 XX 

PFT IMP! IT 




<- 






TFRN/IIMAI RFC:pnMC:p 




--> 


91 XX 


(Help info required) 


<- 


PPTPH 




--> 


nic:PI AY TFVT CHpJn infn'l 




<- 






TFRMIMAI RFCIPOMCIF (CiW^ 




--> 


91 XX 




<- 


PPTPH 




--> 


Ronotitinn nf PFT IMPI IT 




<- 






TFRMIMAI RFC:P0MC:F (CiK^ 




-> 
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Annex G (informative): 
IVIonitoring of events 



Some of the events monitored through the event download mechanism are reported by the mobile each time the event occurs, 
while other events are reported only once (the ME removes the event type from the current event list once the event occurs). 
This is summarised in the table below: 



Event 


Continuously reported 


Reported once 


MT call 


X 




Call connected 


X 




Call disconnected 


X 




Location status 


X 




User activity 




X 


Idle screen available 




X 
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Annex H (informative): 
Change history 



This annex lists all change requests approved for the present document since the first phase2+ version was approved by ETSI 
SMG. 



SMG# 


SMG 
tdoc 


SMGg 
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VERS 


CR 


RV 


PH 


CAT 


SUBJECT 
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B 
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s20 
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B 
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703/96 
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5.1.0 
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r96 


B 
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r96 


C 
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r96 


B 
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1 


r96 


B 
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102/97 
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D 
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r96 


D 
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r96 


F 
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1 
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D 
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1 
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D 
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1 


r96 


D 
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